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
On Sat, Oct 11, 2008 at 5:41 PM, Michael Dale dale@ucsc.edu wrote:
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.
Speaking of, is it possible to enter the duration of a Stream using the MetavidWiki interface? I always get 0:00:00 to 0:20:00, and the Duration / base offset for individual stream files seems to get ignored (is it supposed to be entered in some particular format?)
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)
Maybe we can use null internally and then provide some helper functions:
getValidDuration - returns duration if set, 0 otherwise getValidEndNTP - returns end_ntp if set, '0:00:00' otherwise
This would still help simplify all those cases where a 0 is used when the duration / end_ntp are missing.
fast forwarding is a bad idea..
I'm not saying it's a good idea, I'm just saying it's the best I could do with VLC and some particular flv files.
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.
Just to clarify - I'm only working on implementing local seeks when the server does not support url time encoding (I am not trying to implement smart local seeks when url time encoding is possible but it's not necessary to use it because the requested seek target has already been buffered).
That php media segment script should do that for flv no?
Yes, but at the moment I am trying to keep the process as simple as possible - where someone can just upload the file to a server and enter that file's URL when adding the stream. Injecting flv metadata and using the PHP script will be an option for me when it's all automated.
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)
I am using the VLC method for seeking mentioned in the documentation page: vlc.input.time = <seek destination>. It works when seeking backwards but not forwards. I was not able to figure out how to use the .seek function that is also documented.
if that does not work maybe lock the seeking bar and don't allow it?
Well, seeking is an integral part of MetavidWiki functionality. It's not just about scrubbing the seek bar, it's about clicking on an annotation (transcript) to view the related portion of the video. Without seek functionality, the whole system is crippled.
Fast forwarding is just going to confuse people.
Yes it will, but the alternative in my scenario is that it doesn't work at all (for VLC, for those files).
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 ;)
I'm not sure about the other cases, but I am only concerned about the case where the user clicks on a transcript line with the goal of viewing the related portion of the video. In that case, the needed behavior is as follows:
for files that support url time encoding: * change the url * stop (if playing) * play
for files that do not support url time encoding * set the seek destination * play (if stopped)
I have modified the code so that "change the url" and "set the seek destination" are the same operation that does the right thing depending on the scenario. The problem is the "stop, play", which shouldn't happen in the latter case. "stop, play" currently seems to be realized by calling "play", which is currently implemented as "stop, play" when already playing - so it works perfectly for the former case but not the latter.
So, where to put the logic that figures out what the right thing? I don't think MetavidWiki should be worrying about details like that. Changing "play" so that it does one thing for files that support url time encoding and another for files that don't doesn't make sense to me - play should have consistent semantics. My suggestion is to modify that call from MetavidWiki / mv_stream (whatever route this call goes through) to just call a single mv_embed function that has the semantics "play the portion from time x to time y". mv_embed then figures out the details.
Some other issues we ran into:
"pause" no longer works as pause (it works as stop). In mv_stream there is a comment that says that this is to have mouse_overs working right. What mouseovers are that, and is there another way I could get them to work right so I can make pause be pause? (it is helpful to be able to pause while annotating).
When editing annotations (we use the "add transcript" functionality for our annotations), if you add / save an annotation, and then go back into it to change the time of the annotation, the interface will display a (seemingly harmless) message about the annotation having been erased. Here is an example: --- "MVD:Ht en:boredom3/00:07:40/0:07:55" has been deleted. See deletion log for a record of recent deletions. Return to Main Page. ---
The "remove stream file" button in the stream edit page doesn't seem to work any more.
Please let me know your thoughts - if you have any pointers about how to address any of the above issues, I'd be happy to give something a try.
Best,
Stjepan