video with elastic transcode on media-proxy
Opened this issue · 8 comments
@foresmac is out today, so I'm opening this issue to get my thoughts down after looking through the existing code on media-proxy.
Currently working, is a video is posted to vip and that is correctly saved to an S3 bucket. There is also currently an elastic transcoder workflow configured to take files from an input bucket and deposit a preview thumbnail and the transcoded file in the same bucket used to store the original uploaded file.
The way I believe this should work from here is:
- vip should have a method to transcode video that can accept a Reader, so that the transcode can be completed from an existing or new file
- That method should put the file to the transcoder input bucket, but not the standard bucket. We don't want to have to put a 100MB video file twice.
- There should be an SNS HTTP completion message that is a hook back to the API, which can notify when the transcode is complete so the URL can be stored/updated. That URL is configured in SNS, so vip doesn't have to care about it, it will just hit the API.
- vip should immediately return to the client the S3 URL for the original media but include a field indicating that transcode is pending. This original URL will point to the transcoder input bucket.
- The API will have to match up transcode callbacks with posted media, which may sometimes mean that the completion callback is first, and other times mean that the the item is posted first. This can be a very simple lookup table, here is what transcode sends on completion: http://docs.aws.amazon.com/elastictranscoder/latest/developerguide/notifications.html
I can't think of a simpler way to do this that would be reliable, but please point out flaws you see. Looks like one new endpoint on the API, and very minor changes to vip to support this. This assumes I understand how Elastic Transcoder works, but it looks like a very simple task-based setup.
@scottferg care to comment?
Base on my limited understanding of Elastic Transcode it LGTM. Seems like this is more of a challenge from a UX standpoint on the client-facing app.
When does an application know that the thumbnails are ready to view? When it resyncs with the API?
Yeah, the way I'm thinking about it, the UI would have to accommodate that the thumbnails and transcoded video may be temporarily unavailable while it is processing. Or that could be handled on the API side by potentially not serving certain content while it is processing.
Any client would have to resync (assuming we not using sockets) when the API got the hook back from transcoder to update the media records.
I forgot one thing. vip needs to know the bucket to send the video to, but gets the bucket from the path right now. I feel like the least confusing thing that would be consistent with how it currently works is if the client sends headers like x-audio-bucket and x-video-bucket
It would be weird if the main bucket came from the path but the transcoder buckets were set in config.
We could also just have a convention that the transcoder inputs are always the standard bucket name with -transcoder-audio or -transcoder-video at the end based on the mimetype that vip finds. Maybe that would be better, then the clients don't have to worry about it.
I think client-side if the state is "pending" makes the most sense.
Because this is basically a hack on top of vip, I prefer the standard convention idea. Later when we decide what vmp is we can figure out a better solution.
The pipelines were designed to drop original uploads in a specially designated bucket and make the API call to ET to start the job with a preset ID. The output bucket would just be the same bucket that all other media is put into.
My thinking on this was one of two things:
- Just return the URLs of the finished media since you can know what they should be even before ET finishes its job.
- Do a progressive pull on the Job Status API until it returns "completed" or "error". I tried this with a 4 minute WMV file and it only took 12sec; since Go's http lib handles every request in a separate goroutine, this shouldn't affect other requests. But maybe that's too long to wait for a response?
No you can do long polling but it'll likely break down when you ask the mobile team to support it. I would just have them hit the API.
I think 1 is good, but 2 is a problem in general since that time is very non-definite. Using SNS for 2 with an HTTP hook to the API would allow an immediate return after the file is put to S3. That API endpoint can be even simpler given the URL is returned immediately when the job is created. I guess I left out the step to create the ET job from vip after the file is put to S3.