Hi Sami,
> We're trying to implement some REST file upload functionality from our
> intranet to Matterhorn (1.3.0) via the /ingest/addMediaPackage/{wdID}
> function, and we're running info a few problems:
>
> 1) there doesn't seem to be any parameters for mentioning the series the
> recording belongs to (seriesID or seriestitle). How can the upload be joined
> into a series?
The mediapackage contains a field for the series id. In addition, you should
include a <catalog> entry with its <uri> linking to the series in the series
endpoint.
> 2a) there doesn't seem to be a field for entering the name of the file,
> which results the uploaded file becoming "upload'something'.tmp"
What file are we talking about? If you are referring to the uploaded track,
then you are right, there is no such field, and I am wondering why that would
be needed, since you'll get the full mediapackage back as part of the response,
including a URI to the uploaded track. If you wish to influence the filename,
you'll need to open a bug report, as I don't think that this is supported.
> 2b) there doesn't seem to be a hold-for-trim parameter, but this can be done
> via utilizing multiple workflows (one for trim and the other for direct
> publish)
You seem to have identified another problem here, there should really be a way
to pass in workflow paramters. Please open another ticket and make sure to
mention that this is the case for /ingest and /ingest/{wdID} as well.
> 2c) when using a workflow that enforces trim, the media encoding
> (profile.trim.work) fails in trimming due to ffmpeg getting confused about
> the .tmp -ending of the file with "Unable to find a suitable output format
> for 'path/file.tmp'"
Now I understand why you are concerned about the filename :-)
> Or is this rest call deprecated and should we go for the
> /addZippedMediaPackage instead, which would allow more expressive metadata,
> but would also tax both servers unnecessarily (because of the zipping and
> unzipping involved).
This is definitely the method that is used by most of the capture agents, but I
still believe that we should be fixing the other methods, too.
Thanks,
Tobias
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
