Bryson Jones
Forum Replies Created
-
I might add that Kevin Duggan, Keys (from Dax) and I were noting at NAB that this was in fact, the first archive product to work with CatDV.
I think the confusion comes in that BRU alone doesn’t integrate and that you need the Dax software in order to use it. Similar to how several other software systems (Atempo, Archiware etc.) don’t integrate directly either, you need software to connect them to CatDV. But using that measure, no solutions are “compatible.”
Some people don’t realize that Dax is using BRU.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
Short term, I’m saying have CatDV Pro running proxy creation jobs on those machines.
The worker doesn’t care where the jobs came from so there’s no need for 1 client per worker.
The idea is to split the proxy jobs to multiple machines, think of a Worker as an automated client so…
5 clients and 1 Worker can do the jobs of 6 Workers but you have to run it all manually.
Start x number of jobs on the Worker and then x more on a client and then another “x” more on another client and so on. You’ll be done in no time.
If that’s too much hassle, then you have a great case for spending the money to automate it all.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
Multiple Workers are the easiest to setup and manage.
We use scripts to hand off jobs to ffmpeg and compressor when you want to push the processors. It’s hard if it’s temporary, as you can’t really justify the expense of having it all set up.
Short term, run your clients at night doing the jobs. If you have 5 seats and a worker that’s a lot of horsepower.
Long term there are a ton of solutions and you can really do some cool stuff with scripting clusters of machines. We have one client that can compress an hour of footage in 6 min
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
Scott, you are right on.
One note, maybe keep an eye on CatDV 11 and Server 7 as it will handle the Adobe md way better and split into individual fields among many other md changes in the backend. (All I can say for now but betas will be coming soon.)
We do the “copy fields” thing a lot, especially when delivering to outside systems. As part of your archive action, for instance, you can prep the md and get all those fields set up.
Most of our more complicated workflows include field translations and often concatenations or merges as well. You can set this up easily and have the best of both worlds, but be careful of changes and sync of data.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
It’s a tough one out there. We’ve seen some publishing standards and then there are web standards such as Dublin Core (the dc: you see in Adobe and other products) but they might be hard to manage in a workflow.
Taxonomies are a bit more available and are included in some specs.
You can see a ton in the wikipedia entry for metadata standards.
Here’s a few you might peruse if you need to catch a nap.
Dublin Core
EBUCore
NISO MIX
PBCore
MPEG-7The main issue with “meta data” as we discuss it, is that we oversimplify in the post world. Meta data is always contextual. You have md that you need for masters and then separate md for a raw shot, and then md for an image file and then different md for an image that has a license for the people in that image. And then there’s the md for the music in the master that we mentioned above and then there’s…….. it only goes on. So, you can find standards for each part of your workflow but it’s hard to find one for all aspects of the generalized post production process as we touch so many parts of the data flow.
Ironic that the larger you go in the industry, the easier it gets. Million dollar DAMs regularly support far fewer types of data than CatDV workflows do in a smaller shop.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
Scott, thank you. And yes, our developer meeting was really solid. I’ll reach out to you as soon as we have something to show and there’s a slide deck in the works as well.
There are so many things in the works over there.
I predict more speed and capacity in the short term (we are also testing some more extreme db server configs as well.)
Interface will be fairly similar but the web will be moving quickly and the partner integrations are going to be more and more important so that Squarebox can focus on making CatDV stronger and stronger as a platform and all us partners will be handling archiving, extended automations and other outside workflows.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
(Edit since my ipad post was rife with errors!)
Good timing.
In a few weeks North Shore will be in beta of our CatDV to AWS app.
It will support:
Upload to S3 (you can then life cycle to Glacier) via API which is far more powerful for control and exchange of metadata than simple FTP.
Storage of URL and Object ID in CatDV, as well as the ability to poll for status and see where your asset is in the storage as far as S3 to Glacier.
Restores from S3 (easy.)
Restores from Glacier. (Not so easy but we’re doing it by queuing the jobs for the 6 hour wait time, polling AWS long the way, and then pulling down to original path.)
The big news is that we will have drive imports (AWS import/export). You can prep and our finalization scripts to prepare your drives for shipping to Amazon.
1. Prep the drive with our app.
2. Fill it via Worker actions, recording all the AWS job info and transfer drive info, as it does.
3. Then finalize with our app and ship the drive to AWS. (We create all your signatures, uuid’s and manifests with a double click. We also notify your AWS account to create a job and report that it’s on the way.)
4. Once there, we will link the assets to your CatDV db and then you can manage the assets in CaDV.
Uploading 4 tb via internet won’t be fun, but shipping a drive linked to your db will be fairly easy.
Also, by using only API calls we will retain the media link and you’ll be able to manage assets in AWS completely.
(More info on AWS import/export here: https://aws.amazon.com/importexport/)
Stay tuned. I’ll keep this thread posted as to progress.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
Version 10.0.9 on OS X is right on 1:33 mp3 reports as 1:33
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
I’ve never seen them that far off but I’ve seen wrapper errors “fool” catdv before.
In our case it was QT files mis-reporting their duration while catdv was reading the true media file. Is catdv right or wrong? And have you timed one to see which is correct? And finally, is it 5 sec regardless of length?. That would be weird.
Perhaps try downloading a trial of version 10 and see if that works. 11 is showing next week so that’s a pretty old version now.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
So the workflow is:
Restored “temp” files delivered to folder and temp records created in CatDV, new catalog.
Editors use files and when done delete or flag for deletion (perhaps an auto delete based on time?)
Then the idea is that you would check the status of a “temp” file before re-restoring it?
If that’s the case, then I’d assume the archive device would check that. If not, then draw up the various scenarios and this could likely be implemented via the web API.
On that note, if you all saw the “Automation API” mention in the Squarebox NAB release, that’s something we’ve been discussing for a while. I’m going to post a bit about what that is next week, but basically we’re seeing the 1 to 2 second time for Worker Node actions reduced to just a few milliseconds for updates done through the Web API. Everything CatDV automates can be faster now.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com