On Sat, Oct 11, 2008 at 5:41 PM, Michael Dale <dale(a)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