Batch uploading and media API

[webb]

We are currently using the FTP Batch ingest method to send our videos into the Brightcove studio.  We are also using the media api for integration into our CMS for video tagging and other functions.

I'm noticing that there seems to be a lag from when a video is available in the BC studio vs. when it shows up in the media API and it's not due to the API caching.  When a video first shows up in the BC Studio is shows processing and there are no renditions available, at that point it will not show up in the media api (using the find_modified_videos method with a different date date stamp to help reducing the caching effects).  As soon as there is one rendition available it will show up in the media api.

So is it a requirement that there must be at least one rendition before a video will show up in the media API?  If so, is there a way around that or an api that we can use for CMS integration that has lower cache times and will show videos as soon as they show up in the BC studio?

The problem is the total time it takes from when we drop the video at the Batch FTP location to the time it takes to show up in the API seems to be 15-20 minutes or even longer at times.

[BC-Sean]

Yes, there is a requirement that any video coming back through the api have at least one rendition. 

The api returns videos that playable.  That means currently scheduled, active and the video has at least one video to play back if loaded into the player.  We can't assume transcoding will succeed or that a rendition will eventually show up we want to be cautious is the data we return so that anyone using this data to drive customer facing pages won't look the fool.

Hope that makes sense,
Sean

[webb]

That makes perfect sense for front end applications.  Have you guys ever considered doing an API or adding methods to the exisiting one that is geared more towards CMS integration?  Lower cache times, showing videos regardless of status, indicitation of if a video is shared or not, etc.  Thank you for getting back to me so quickly.

[BC-ChrisD]

---

webb wrote:
That makes perfect sense for front end applications.  Have you guys ever considered doing an API or adding methods to the exisiting one that is geared more towards CMS integration?  Lower cache times, showing videos regardless of status, indicitation of if a video is shared or not, etc.  Thank you for getting back to me so quickly.

---

We absolutely have considered this. There are a few situations where steps we took to make client applications more robust significantly degrade the performance of CMS integration type applications.

We haven't come to any decisions but it's basically a trade off of speed and scale.  One possible solution would be to provide a second end-point that wasn't cached but was limited far more then our current end-point. The less we cache, the more demand it creates on the system and we first and foremost have to protect our production systems from failure.

Message Edited by BC-ChrisD on 12-16-2009 01:29 PM

[webb]

Thank you Christopher, one last question and I should be done :) ... If switched our process from using the Batch FTP method to using the Write API Upload method to get videos into the BC Studio would that improve the speed at which they show up in the studio and thus the API?  So basically is the API upload faster to get videos into the system than the Batch FTP process?

[BC-ChrisD]

It would likely be faster to upload individual videos via the Media APIs instead of Batch.

The Batch manifest system utilizes timed processes to pick up new content and there are a few steps to the process. So this means there is an arbitrary amount of time that could elapse after you upload a file. It could be picked up after a few seconds or up to several minutes. Once the file actually is through the Batch manifest system and enters the transcoding and "processing" phase(copied to CDN) there is no time difference.