Last modified: 2011-01-14 20:19:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28663, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26663 - Request for selecting a portion of media for playback
Request for selecting a portion of media for playback
Status: RESOLVED FIXED
Product: mwEmbed
Classification: Unclassified
Video player (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Michael Dale
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-11 00:30 UTC by Theornamentalist
Modified: 2011-01-14 20:19 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Theornamentalist 2011-01-11 00:30:25 UTC
Hi,

Is it feasible to introduce two new parameters into the Ogghandler? They would be to view/listen to a chosen portion of the original; something like:

|starttime = 0:00:00<br>
|endtime   = 0:00:00

I think this could reduce the amount of space used up by derivatives of larger files with points of interest at a particular portion. An example of what I mean is here:http://commons.wikimedia.org/wiki/Category:Betty_Boop%27s_Bamboo_Isle where many portions exist, and the movie files ''really'' take up a lot of space. In place of this, having a single movie file and just having parameters to designate which portion is shown would greatly reduce the size of files held in Commons. This could also have other applications for verifying particular parts of the media, like in Wikisource. Using Sequencer (http://commons.wikimedia.org/wiki/Commons:Sequencer) does not solve this problem as it creates separate files. I imagine the specified parameters to either point to the positions (as in having the original file load) or truncate the non-selected parts; either way I think this is a capability that would be beneficial to a lot of projects.
Comment 1 Derk-Jan Hartman 2011-01-12 09:48:16 UTC
This would probably be better/easier to implement in the Timed media handler of mwEmbed. Moving to that target.
Comment 2 Michael Dale 2011-01-12 18:06:22 UTC
We did originally work on getting oggz_chop ( server side video segmentation)  integrated on Wikimedia but ultimately were not successful in integration because of scalability concerns. We were successful in helping get it integrated at InternetArchive.org see a blog post I wrote about the feature a while back http://metavid.org/blog/?p=191

What can easily add to the Timed Media Handler is http based seeks. This would seek to the start time then stop at the end time ( but the browser would buffer more than it needs since there is presently no way in the HTML5 spec to stop the video from buffering ). But it would be a good start, and depending on how the temporal url standard develops and the amount of time and interest we can upgrade the http based seek system to better handle start / end times. 

Will update this bug once I have the feature in the TimedMediaHandler code
Comment 3 Theornamentalist 2011-01-13 04:28:37 UTC
(In reply to comment #2)
> We did originally work on getting oggz_chop ( server side video segmentation) 
> integrated on Wikimedia but ultimately were not successful in integration
> because of scalability concerns. We were successful in helping get it
> integrated at InternetArchive.org see a blog post I wrote about the feature a
> while back http://metavid.org/blog/?p=191
> 
> What can easily add to the Timed Media Handler is http based seeks. This would
> seek to the start time then stop at the end time ( but the browser would buffer
> more than it needs since there is presently no way in the HTML5 spec to stop
> the video from buffering ). But it would be a good start, and depending on how
> the temporal url standard develops and the amount of time and interest we can
> upgrade the http based seek system to better handle start / end times. 
> 
> Will update this bug once I have the feature in the TimedMediaHandler code

Thanks Michael. As an example of a way that this modification could help in verification on Wikisource (as seen, for example http://en.wikisource.org/wiki/The_Babes_in_the_Wood), I've put together a page which features a silent film http://en.wikisource.org/wiki/Daydreams. The time location seen on the left could link to the portion which is defined by the start and end times, and allow for Wikisource to validate either text which appears on screen or for the transcription of the audio.
Comment 4 Michael Dale 2011-01-14 20:19:16 UTC
I have added temporal url support in r80284 and deployed it to the gadget. 

Its based on: 
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-dimensions

This works on video pages like so: 
http://commons.wikimedia.org/wiki/File:Folgers.ogv#t=10 ( start at 10 second go to end ) 
or 
http://commons.wikimedia.org/wiki/File:Folgers.ogv#t=10,20 ( from 10 seconds to 20 seconds )

Until the updated timed media handler extension is deployed you have to use the following template on videos to support time offsets ( Once we deploy the updated timed media handler we can switch the template syntax over to the proper format  )
http://commons.wikimedia.org/wiki/Template:Temporal_Media_Fragment

Here is the example on commons:  
http://commons.wikimedia.org/wiki/User:Mdale/TestTemporalUrls

Here is an example on wikisource:
http://en.wikisource.org/wiki/User:Mdale/TestTemporalUrls?withJS=MediaWiki:MwEmbed.js

If there is community consensus we could turn it on by default for wikisource. ( mwEmbed has been enabled by default in some other small wikis )

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links