I am cc'ing the metavid dev list,
in terms of duration... the stream db entry needs to know that info ie
duration should be stored in the DB .. it won't have any way of
validating the text transcripts contributed are in range without
duration. If operating mv_embed in "stand alone mode" then maybe the
approach you mention is applicable... but i would use null or
'undefined' over 0 since what if a clip that is part of a sequence is
.4s long and then we round down or something bad happens. (ie we should
do what the whatwg recommends for that value)
fast forwarding is a bad idea.. if the client plugin does not support
revealing how much of the video is been download / available for a local
seek... you should just issue a url update and remote seek. That php
media segment script should do that for flv no?
If no stream server is available (ie using mv_embed in stand alone mode)
then try using the plugin seek function (ie client side http seeking) if
that does not work maybe lock the seeking bar and don't allow it? Fast
forwarding is just going to confuse people.
Switching the "update_url" call to a direct play call seems like a bad
idea because we use the update stream src url in many cases where we
don't necessarily want to play... if you do add that function in you
will probably want to keep the older function and only put in the new
call where appropriate and ofcourse do lots of testing ;)
--michael
Stjepan Rajko wrote:
> Hi Michael,
>
> I've made some progress with local seeks - when you seek from within
> mv_embed (vs. from MetavidWiki) it doesn't stop/replay. I've now also
> made the VLC player work with local seeking - but I'm having weird
> problems with the plugin when you try to seek to the future (I am not
> sure yet whether it has to do with seeking to the future, or seeking
> to a point in the file that has not been played yet). I am not also
> sure whether it has anything to do with my encoding of the (flash)
> files. For now, I have it fast-forward to do forward seeks (super
> lame, but it's all I could figure out for now).
>
> Also, I have a question about duration when it is not specified in the
> URL. For the start offset / ntp (in a media source) it makes sense to
> set to 0. For the duration / end_ntp I left it undefined, and then
> had the player fill in the value when it gets it. But, in a lot of
> cases (I think all I've noticed) the default value used when duration
> / end_ntp is undefined is simply 0. So, should I just set the
> duration / end_ntp to 0, and then change it when the player gets the
> true value? I think it would make a lot of cases simpler. Do you see
> any problems with this (I'm basically proposing to use 0 as a special
> value instead of using null as a special value, which seems to be OK
> since no video should have a true duration of 0)?
>
> Finally - when you click on a transcript item it looks like
> MetavidWiki issues a updateSrcTime request followed by a play request.
> This has the desired end effect with the way I have local seeking
> working, but the bad side-effect of stopping / reloading. Instead,
> could we have MetavidWiki just call a single mv_embed function that
> would do the appropriate thing depending on whether we are local
> seeking or url seeking? (something like playByTimeReq?).
>
> Stjepan
>
Can the HTML5 video tag Poster be spported?
eg: <video
src="http://localhost/drupal/oggtheora/play/18"
poster="/drupal/files/oggtheora/images/18_performance.png"
/>
Is there any way to turn off the embed/download clip
options?
Are there any newer version of MV_embed?
Win a MacBook Air or iPod touch with Yahoo!7. http://au.docs.yahoo.com/homepageset
Hello all,
Being the official summer of code pencils-down date, on Monday I
drafted a little summary of work I was able to do for my gsoc project
with Michael's direction and help . The draft is posted on:
http://metavid.ucsc.edu/wiki/index.php/Talk:Mv_Embed (the "PHP based
Flash Media Server" work was all Michael)
The plan now is to iron out some things left to iron out for the next
release, but I just wanted to take the "pencils-down" moment as an
opportunity to thank WikiMedia and MetaVid for letting me work on this
project as a part of summer of code, and special thanks to Michael for
being such a helpful mentor. I've learned a ton :-)
Kind regards,
Stjepan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have merged the experimental branch to the trunk so if you were
following the experimental branch no need to do that now... please
commit/patch directly to the trunk from now on :)
http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/MetavidWiki/
We should be able to relaunch the main metavid site shortly if you find
issues with the code and find mediaWikis bugtracker too verbose you can
add issues to:
http://mvbox2.cse.ucsc.edu/mvw-exp/index.php/TODO
or mail it directly to this list: metavid-l(a)lists.wikimedia.org
(still have to update that site to the trunk... will do that shortly)
here is a draft of the release notes:
== Unified Search ==
* new unified search model groups and aggregates relevant semantic
metadata per search
* advanced search improvements
* improved autocomplete suggestions/display
== Improved Skinning Support ==
* improved skin infrastructure to support the skin created by the
Participatory Culture Foundation
== Mv_embed ==
* support multiple stream selection, supports flash stream type (Summer
of code Student *stjepan*)
* improved video control skinning (SOC Student *stjepan*)
* flash media server added for serving portions of flvs to arbitrary
clients. (based on FLV4PHP)
* Also See http://metavid.ucsc.edu/wiki/index.php/Mv_embed
== Massive security review (thanks '''tstarling''') ==
* properly escaped all values outputted to browser and database
* proper use of database wrapper functions
* closed some security holes (running older versions of metavid is a bad
idea please update now)
== Updated compatibility to JQuery 1.2.6 ==
* updated to latest and greatest (faster, leaner etc)
* Also see http://docs.jquery.com/Release:jQuery_1.2.6
== Updated compatibility to latest metavidWiki version *1.13* ==
* Also see
http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_13_0RC2/phase3/RELEASE…
== Updated Compatibility to latest Semantic MediaWiki 1.2 ==
* faster, lazyloading of all classes, better db structure, + lots more
* Also See http://semantic-mediawiki.org/wiki/SMW_1.2
peace,
michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIpNR0PPG4QoAtd8MRAteKAJ46uVGTxM/XPjsUoiDm98zE3x8buQCeKhf+
JGNDQxPiYcPNvQaiK/gf6x8=
=WroL
-----END PGP SIGNATURE-----
yea lets put player discussion on-list : )
my thoughts on the questions:
> Should the skin show up right from the beginning (i.e., with the
> thumbnail picture)?
I think we should include it (if the "controls" attribute is set to
true) ...
Youtube does it .. in the future we could support jump to time
seeking... where the user drags the seek bar (before the video has
started playing).. update the video thumbnail with jpegs and the new
timecode as they drag and then just seek to that time onMouseUp (we
already have (updateThumbnail and updateVideoTimeReq ) ;)
> Should we migrate the icons/functionality accessible in the corners
> of the thumbnail (download, choose player, ...) to the icons on the
> control bar (options icon etc.)
Yes.
> How do we deal with the case where the requested width is
> insufficient for the entire control bar? impose a minimum width?
> Scale things down?
Bellow 320x240 I think we should hide the seek bar. You will probably
have to do some hackery to get it to do dynamic layout widths properly.
Let me know if you run into any css issues that seem insurmountable...
I got a lot of flv info today and it seems there is no perfect seeking
solution without re-encoding flash content because flash can only seek
or play media from a given keyframe. (it does not seem capable of
decoding from previous keyframe and then skipping/dumping unrequested
content to start playing at the time requested :( I will look at the
existing media on archive.org see how much keyframe granularity they
have...
--michael
Stjepan Rajko wrote:
> Hi Michael,
>
> I got started with the reskinning and have some questions. You can
> see my modest beginnings at:
>
> http://urbanstew.org/MediaWiki/extensions/MetavidWiki/skins/mv_embed/sample…
>
> For now, the new skin will show up only if you play something using
> flowplayer - it will materialize (poorly) the control strip, and the
> pause/play button will work (but not change its image). I left the
> old controls for now as well.
>
> My questions are:
>
> * Should the skin show up right from the beginning (i.e., with the
> thumbnail picture)?
> * Should we migrate the icons/functionality accessible in the corners
> of the thumbnail (download, choose player, ...) to the icons on the
> control bar (options icon etc.)
> * How do we deal with the case where the requested width is
> insufficient for the entire control bar? impose a minimum width?
> Scale things down?
>
> Let me know if you'd rather I send these questions out to the list.
>
> Thanks!
>
> Stjepan
>
Hi
I keep getting errors like this in my apache logs for some ogg files
which don't play at all in Metavid, yet other ogg files work fine.
What could be the problem?
[error] [client 127.0.0.1] Accept CMML 1.000000, Accept ANX 1.000000\n
[error] [client 127.0.0.1] ma_anxenc t=0:00:00 id=(null)
(0.000000/81.000000)
Thanks
Miano.
should be fixed and committed shortly :) ... the branch I have been
working off of lately is
http://svn.wikimedia.org/viewvc/mediawiki/branches/MetavidWiki-exp/MetavidW…
this is because several site-breaking big changes are happening with
development/deployment of the new skin ("unified search", "semantic
helpers" for annotations, skin enhancements, clip views & search digest
and the in-development flash fall back support that Stjepan Rajko is
working on :)
This should hopefully be merged back to the main branch in early august
before we launch the site.
looking forward to john's import script :)
another thing discovered in conversations with Marcus (lead developer of
semantic mediaWiki) is that [[property:=value]] has been deprecated in
favor of [[property::value]] ... so all import scripts should be updated
accordingly ie [[Spoken By::Person]] rather than [[Spoken By:=person]]
also for metavid-l check out
http://www.gossamer-threads.com/lists/wiki/foundation/138776
for an announcement about my future involvement with
metavid/wikipedia/kaltura ;)
peace,
michael
Silvia Pfeiffer wrote:
> Hi Michael,
>
> Having used metavidwiki today to import some random html annotations
> from HANSARD into it, I noticed that your CMML representations of the
> annotations aren't quite "conformant", e.g.
> http://metavid.ucsc.edu/wiki/index.php?title=Special:MvExportStream&stream_…
> .
>
> This is quite a funny one: You have used as time specification "ntp"
> everywhere, where instead it should read "npt" (normal playback time).
> :-)
>
> Also, there is no "description" element in the "head", but rather you
> should use a meta tag for that in the form:
> <meta name="description" content="Legislative Assembly, Thursday 5
> June 2008"/>
>
> John is currently writing a ruby script to import cmml into
> metavidwiki. I'm sure he'll be happy to share once done.
>
> Cheers,
> Silvia.
>
Hi,
As part of some work I'm doing with the Annodex association and
some clients I have packaged up Semantic MediaWiki and MetavidWiki for
Debian.
These packages are now in the unstable archive. They should make
their way into testing and therefore Ubuntu in the next week or
so.
If you have the time please test them out and let me know if you
find any problems.
Cheers,
--
John
http://www.inodes.org/
MetavidWiki extension has been written to take advantage of some of the
scalability features of mediaWiki. So performance should be scalable in
the same way that mediaWiki scales. (ie use a php accelerator,
memchache, squid proxies, mysql slaves & masters etc).
So while its requirements are certainly higher than just vanilla
mediaWiki (metavidWiki also includes semantic mediaWiki)... it should
scale in a similar way.
I can share the relative speed of the two ogg segmenting media serving
solutions:
mod_annodex ... is not that scalable since it does not cache seek
offsets and rewrites ogg pages as it sends out the stream. It takes
around ~700ms for both a cold and hot seek segmented media serving.
oggz-chop .. is faster ~190ms for cold seek and since its just byte wise
serving (does not rewrite media pages) the second request for that
segment will come from OS RAM disk cache ie ~10ms so with a good raid
and sizable amount of ram you could likely only be limited by the
bandwidth of your media server.
oggz-chop is still kind of new but you can grab it from the svn at:
http://svn.annodex.net/liboggz/trunk/src/tools/oggz-chop/
It has a few minor issues with a few frames freezes in VLC and possibly
some audio sync issues with quick time component.
I think Conrad/kfish may be soon addressing the above mentioned issues
and pushing it into the Debian repos soon... I will have to check with him.
peace,
--michael