Rajat, Right now our player provides more than just stop pause and playback functionality. It also allows you to seek to segments of video that have been automatically detected, leave annotations (coming soon), etc. So these player functions would need to be updated as well. I'd be happy for this GSoC project to chop off just the processing part of the problem, then move on to the playback issues if there was time (some institutions use different players for playback).
Regards, Chris On Thu, 22 Mar 2012 15:36:12 +0530 Rajat Jain <[email protected]> wrote: > Hello Rüdiger, > > I understand what you want to say, but I am skeptic about the need of > such a tool in the player. The whole point of developing the > application is to make sure that the students don't have to watch the > complete length original videos, and if that is the case, the viewers > don't know where they have to point there playback time to (unless > told by another viewer who has watched the video). Generally we use > the time bar to move back and forth in video we have not seen earlier. > However, we can think of integrating some sort of mechanism which > will tell us the exact time of current frame in the original video, > if the student is somehow unable to understand the concept and wishes > to see the same topic explained in original video. > > Regards > > On 22 March 2012 13:25, Ruediger Rolf <[email protected]> wrote: > > > Hi Chris, > > > > I just want to add an additional level of complexity to the > > discussion. If we want to add this feature to our engage player we > > have an interesting problem to keep consistency. The videos with a > > different playback speed have a different lenght from the original > > video. If I select a different speed I have to normalize all > > navigation elements. An example: if the video would be at 0:45 > > minutes in real time and I decide too speed the video up now to > > 1.5x I would have to jump to minute 30 in the faster video. If I > > click on the segment/chapter that would be at 1h I will need to > > jump to 0:40 in the video. So there needs to be some JavaScript > > hacking for the player too, to make sure that that everything acts > > like expected here. > > > > Rüdiger > > > > Am 21.03.2012 22:30, schrieb Christopher Brooks: > > > > Hi Rajat, > >> > >> I have been going through the project ideas of the *openCast*, > >> and I > >>> came across the idea of *Variable Playback Speed**. *However I > >>> have some doubts regarding the project. Such as how are we going > >>> to reduce the time of the playback. Are we going to increase the > >>> speed of the playback (which I don't believe is the idea), or are > >>> we going to remove some part of video from the original file ? > >>> Can anyone help me. Or does anyone know how to contact the mentor. > >>> > >> There are two ways to do this, either increase the speed of > >> playback, or compress playback by removing uninteresting parts of > >> the video (called "video skims"). Either of these methods are > >> interesting to me as a feature, but require a different background. > >> > >> Increasing the speed of playback would require investigating > >> gstreamer, specifically how gstreamer can read and write to file > >> descriptors in order to hook it up with the SOX project to pitch > >> shift audio so it doesn't sound too "chipmonky". Fairly minimal > >> java code would need to be written for this integration, and the > >> majority of code would need to be gstreamer related with a little > >> UI work to show alternate videos. > >> > >> Creating video skims is much more involved, but a much less naive > >> approach to speeding up playback. You can think of video skims as > >> similar to lossy compression for video, where duplicate frames or > >> frames of video that aren't important are removed. e.g. when an > >> instructor has written something on the board and hasn't said > >> anything because he is waiting for students to transcribe it, you > >> can delete some seconds video. You could imagine some parameters > >> to creating skims to determine how aggressive they might be (e.g. > >> ignore one video feed over another, ignore audio, etc.). > >> > >> Of course, both approaches could be used together as well, to > >> create a lossy high speed playback. > >> > >> I'm willing to mentor this project, but it does require a fair > >> amount of self study and self interest. It's not by any means a > >> trivial project, and would probably require hanging out in > >> #gstreamer and asking alot of questions. A background in > >> gstreamer would be great. Feel free to drop me a question if you > >> have any more thoughts, > >> > >> Chris > >> > > > > > > -- > > > > ______________________________**__________________ > > Rüdiger Rolf, M.A. > > Universität Osnabrück - Zentrum virtUOS > > Heger-Tor-Wall 12, 49069 Osnabrück > > Telefon: (0541) 969-6511 - Fax: (0541) 969-16511 > > E-Mail: [email protected] > > Internet: www.virtuos.uni-osnabrueck.de > > > > > > ______________________________**_________________ > > Community mailing list > > [email protected] > > http://lists.opencastproject.**org/mailman/listinfo/community<http://lists.opencastproject.org/mailman/listinfo/community> > > > > > > To unsubscribe please email > > community-unsubscribe@**opencastproject.org<[email protected]> > > ______________________________**_________________ > > -- Christopher Brooks, BSc, MSc ARIES Laboratory, University of Saskatchewan Web: http://www.cs.usask.ca/~cab938 Phone: 1.306.966.1442 Mail: Advanced Research in Intelligent Educational Systems Laboratory Department of Computer Science University of Saskatchewan 176 Thorvaldson Building 110 Science Place Saskatoon, SK S7N 5C9 _______________________________________________ Community mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/community To unsubscribe please email [email protected] _______________________________________________
