[
http://opencast.jira.com/browse/MH-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25556#comment-25556
]
Robert Robere commented on MH-6385:
-----------------------------------
I'm still unable to log into the crucible, and infra still hasn't gotten back
to me. So I'll respond to the questions here:
--Line 132
--Adam McKenzie says:
--This will dump all of the files in the main directory of the storage
directory if I am not mistaken. Would it be possible to put them in the
workspace associated --with the tracks. That way if we have two media files
named NCAST.mp4 from different classrooms for example they won't overwrite one
another if we try to --process them at the same time.
I upload the files to associated workspace later, this is just the directory
where I do the local processing. You're definitely right about the fact that
these could definitely be overwritten. Is the track's workspace local or
remote? If it's local, I could certainly do the processing there. If it's
remote, I guess a random temporary filename would be the best way to do the
local processing...?
--Line 240
--Adam McKenzie says:
--Sorry if I have missed it. But would it be possible to determine which of the
tracks is the screen and be able to make its flavor as presentation so that it
will ---be processed for segmentation. If this is beyond scope ignore me
I'm not sure if this is beyond scope or not... I suppose it depends on how
general this operation handler is. If we're splitting arbitrary files, then I
guess additional metadata would have to be passed in to help select which track
is which. The NCast card just gives us two copies of the same video stream, so
wouldn't they both be the screen? Or am I just completely misunderstanding the
question...
--Line 284
--Adam McKenzie says:
--Is there a particular reason you are setting all of these values to the
default? Do you change them anywhere else and need to change them back?
The default values are actually not 0. Setting all of these properties to 0
sets the buffers to an unbound size. Whenever I tried to set the queue to a
finite size, the pipeline would not preroll correctly because the queues would
overflow. I asked on the gstreamer irc, and this was the response that I got.
--Line 432
--Christopher Brooks says:
--why only looking for quicktime tracks?
I was looking for quicktime tracks as they were the kind of tracks I originally
wrote the pipeline for. It's not hard to modify though -- what kind of other
video tracks could be processed by this operation handler?
Other than that, I fixed all the variable names and exception problems. Sorry
about posting here, I just didn't really want to wait.
> Convert gstreamer pipeline into a workflowoperationhandler and include tests
> ----------------------------------------------------------------------------
>
> Key: MH-6385
> URL: http://opencast.jira.com/browse/MH-6385
> Project: Matterhorn Project
> Issue Type: Sub-Task
> Components: Administrative Tools
> Affects Versions: 1.2
> Reporter: Christopher Brooks
> Assignee: Robert Robere
> Fix For: 1.2
>
> Attachments: MH6377.diff, MH6377.diff, ncastsplit.xml,
> NCASTVideoSplitWorkflowOperationHandler.java,
> NCASTVideoSplitWorkflowOperationHandlerTest.java, split.mp4,
> split_without_tracks.xml, split_with_video_and_tracks.xml,
> split_with_video.xml, split_with_wrong_video_mimetype.xml
>
>
> See
> https://opencast.jira.com/svn/MH/contrib/workflow-operation-handlers/1.1.x/template/
> for a (not quite finished) template for making workflowoperationhandlers.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
