Mike Most -- account bouncing, bad address
Forum Replies Created
-
Are they in a folder called “OMFI MediaFiles” at the root level of the drive? And did you delete the media database files (“msmxxxx.mdb and msmxxxx.pmr)?
-
Not crazy. I set up two systems to do this, never had a problem. It was, in fact, much simpler in part because the Kona port was much more reliable, and in part because it meant that the system only needed one connection to a control router regardless of what it was running.
-
You can use it without deck control. I’ve used it for live capture. One nice thing about the Kona series is that it can read RP188 time code, so if the device you’re capturing from supports this (it’s basically part of VANC) – almost all Sony cameras do, I was capturing from F900’s – you get time code directly from the SDI stream, making “deck control” unnecessary. If you set things up right, you also get embedded audio.
-
DigiBeta is NOT uncompressed. It is a compressed format, albeit very effective and relatively mild compression. If you are coming out of the tape deck over SDI, what you’re getting is a “decompressed” version of what’s on the tape, because SDI is, by definition, an uncompressed transport. It is always best to avoid concatenating codecs, so if you can, working with the material in a 10 bit uncompressed form is as transparent as you’re going to get, given that the material will be recompressed when it’s recorded back to tape.
-
I’ve never had this problem on multiple SR decks. You might try working around the sync issue by setting the SR deck to Input Video Reference. If you still have the problem, you’re likely looking at an issue with the deck itself.
-
The RS422 port on the Kona 3 can be used with Avid and works just fine. In fact, that’s exactly how I set up two systems.
-
Hmmm. Good point. You’re right, since my perspective is generally network television and features, I often don’t think about the cable networks – a mistake in this case because, as you point out, a number of them are not headquartered in L.A. or New York.
While we’re on the subject, I would now probably add the Spanish language networks, putting Miami on your list.
-
Price and technology has nothing to do with it. You have to have enough work to justify that many seats. I think Bob’s point was that the only places in the USA that have that volume of work are Los Angeles and New York. And, in general, he’s right.
-
The math is very simple. 70MB/sec = approx. 4GB/min. So, for your 30GB, that’s a little under 8 minutes. The 70MB/sec is not aggregate bandwidth, it is bandwidth per 1Gb connection. So if your server has 4 gigabit ports trunked together, you could reasonably expect 4 clients, each with a 1Gb connection, to be able to pull somewhere close to 70MB/sec each. That’s an aggregate bandwidth of 70×4, or 280MB/sec, provided the disk array that is serving as the central storage can supply that, and assuming the server itself doesn’t add considerable overhead (it shouldn’t). Adding clients beyond that will, of course, impact the ability of each to achieve this number, but only if all of the clients are pulling material at the same time – hence the logic of working locally and copying to the central server.
Bob, feel free to correct me if I’m wrong.
-
>DVCProHD (which is 100Mb/sec) requires 13.9 Mb/sec
>Ethernet will give you 50Mb/sec, ethernet with jumbo frames will give >you 70Mb/sec (and greater, but 70Mb/sec min). So there is no issue >putting 13.9Mb/sec into a 70Mb/sec data pipe.Bob, you’re probably confusing a lot of people by freely using “Mb” to represent both megaBITS and megaBYTES. The common nomenclature is Mb for megaBITS, and MB for megaBYTES. They are not the same thing (not even close) and need to be differentiated if people are to make any sense of what you’re saying.
For example, translating what you have posted above, what it should say is:
DVCProHD (which is 100Mb/sec) requires 13.9 MB/sec.
Ehernet will give you 50MB/sec, ethernet with jumbo frames will give you 70MB/sec..etc.