[Drew Lahat]

This!

(As in, just run into this problem and wish the CC feature set in Premiere was more… mature by now.)

[Drew Lahat]

As of Feb. 2016, the bar is at $2,000 and you have three options: the aforementioned Canon X25, JVC GY-HM200, and Sony X70. All at $2,000, and pretty darn good cameras for that price point.

I think Cat5 baluns are a horrible idea for this application; they’re bulky, not meant for moving situations, and there’s nothing about Ethernet connections that’s very sturdy, especially if you have roving cameras. At this day and age I’m not even talking about analog signals, I think that’s utterly out of the question, and digital HD video over Cat5E (let alone Cat5!) can be very unreliable. This is all from personal experience, selling Geffen, Kramer or Extron adapters to customers a few years back and having to deal with complaints and problems.

So stick with BNC cables and HD-SDI.

What IS a very viable option to you is today’s new ultra-cheap HDMI-to-HDSDI adapters. The Chinese have “cracked the code” and you can find a bunch of those on Amazon for $40 apiece (yes, they’re all the same product with different labels slapped on it…). And they work! I just ran the exact setup you described – filming concerts on a (very?) low budget – and had a couple of those on hand. They did the job without an issue. Those cheaper adapters used to be limited on the type of signals they could handle (anything besides 1080i and 720p60 was iffy), but they got much better so basically if your video switcher can handle the HD format these adapters will, too.

So here’s an HD-SDI camera for $170: you buy a $130 HD handycam, slap the SDI adapter, and voila! Your switch already takes SDI so you’re all set from there. Of course you can use any camera with an HDMI out.

[Drew Lahat]

Of course a proper production intercom system (Clearcom/Telex/etc.) is the right thing to do and by far the best option. If you don’t have a proper integrated studio system (Triax,SMPTE fiber, etc.) they can be a challenge to utilize with separate wiring and all… and the wireless systems are expensive to rent for productions who can’t afford proper studio setups to begin with.

What I propose is walkies – particularly the ubiquitous Motorola CP200 2-way radios. Those can be rented anywhere you get production rentals, here in L.A. it’s easy to find them for $10 apiece. They’re professional and rugged, and I’ve used them on a couple of productions as intercom and they worked pretty well for that purpose. Still gotta figure out VOX or avoiding PTT for the producer all the time.

[Drew Lahat]

So basically this error can be caused by anything the sun. 🙂 About as specific as Avid’s “Bus Error in Main Thread at address 0x0″…

[Drew Lahat]

Oh Bob… I should add “fool” to my business card. To further horrify you, I’ve done consulting and system integration in a professional capacity for (happy) clients around L.A. for the past 8 years. I should contact them all to notify them about the nutcase I am.

Back on topic, 4Gb fiber was an excellent and robust technology for quite a while, and its sustained 380MB/s is at a sweet spot for online HD workflows. If a facility has it working, it’s still working. If they’re considering a multi-year upgrade plan, then of course 4Gb is obsolete. I tend to forego 8/16Gb FC and recommend 10GbE instead.

In your universe everyone has moved on. In mine, it’s an ongoing process as it is gradually phased out.

PS Reminds me of my visit to Modern Videofilm when they said they still had some Cat3 in use running 10Mb/s Ethernet. In 2010.

[Drew Lahat]

Hi Eric,
I do believe that the Apple/LSI cards are by far the most affordable option to have 4Gb fiber on 10.10 or 10.11.

I haven’t seen it with my own eyes yet; I did recommend that route to a colleague, and he just updated me that it’s been working well for the past week and a half – new Mac Pro and the Apple/LSI card in a (Sonnet) Thunderbolt box. He did have some glitches prior to that but wasn’t able to isolate the cause, whether or not it was related to the fiber card.

[Drew Lahat]

Yup, I’m totally getting specific. 🙂

Thank you for mentioning RP187, the introduction in it basically sums everything up:

Most video standards documents specify tolerances for individual picture blanking edges; center and aspect ratio are only implied by nominal blanking values, and vary as the blanking edges move within permitted tolerances. Modern techniques of post-production […] demand a degree of precision not afforded by the implied definitions of center and aspect ratio.

Chris Wright wrote:

This is because the pixel aspect ratio is different from the production aperture. The picture needed to be centered after the crop for a perfect pixel ratio, called the clean aperture. Why? because of overscan. And guess what happens when codecs ignore the overscan? your pixel aspect ratio goes awry!

Exactly! Case closed. 🙂

[Drew Lahat]

Thanks Chris, but not relevant to this discussion.

I’ve been doing a bit more reading to get to the bottom of this. As en engineer and online editor, I underestimated how lax the “official” SD aspect ratios were. There’s a fairly good discussion at https://en.wikipedia.org/wiki/Pixel_aspect_ratio, and I found https://toolbox.sgi.com/TasteOfDT/documents/video/lurker/pixelaspect.html“>another insightful discussion from 1999 SGI forum, albeit one that adds as much as it confuses.

So what’s going on?
Warning – this is not a discussion for beginners; it will make your head spin 😉

1. Anything that has to do with SD is based on analog standards. We’re so used to live in our exact, digital HD world that we forgot the relatively lax tolerances that analog video called for. Mainly, the “active image area” was well-defined but what laid beyond greatly varied. The “entire frame” had many different sizes and aspect ratios that were never standardized! ” Consecutively, the pixel sampling frequencies in use today are industry conventions, not stated in any spec.”

2. The standards were often lacking. CCIR-601never defined pixel aspect ratios. (Ironic, since it’s called “encoding parameters of digital television for standard 4:3 and wide-screen 16:9 aspect ratios”.) It barely even mentions pixels; everything is derived from analog sampling frequencies.
The first revision of ISO/IEC DIS 2-11172 (better known as MPEG1) defined aspect ratios which “the committee seems to have made up”, disregarding Rec. 601. Rev.2 didn’t fare much better, and added “we presume that a certain degree of tolerance is allowable.”
The spec for MPEG2 (which all DVD players use) allowed for the proper aspect ratios but didn’t enforce them, leaving plenty of room for interpretation.
Lastly, SMPTE RP 187 (from 1995) was supposed to help clean the clutter, but instead made up its own impractical pixel aspect ratios, so it was ignored by the entire industry…

3. What’s causing our specific pillar-box issue and AR mismatch? SD video was never meant to be 720 pixels wide(!) – but 704 pixels. The extra width (8 pixels on each side) was added by Rec.601 as a safety margin corresponding with the horizontal blanking period, meant to be buried in the overscan area. 704×480 at a 1.21:1 PAR indeed translates to 16:9!
In our HD age all this got increasingly forgotten, so DVD and TV manufacturers treat those extra pixels as “active image”, we editors and producers get upset if stuff doesn’t look right at the edges, and the aspect ratios get mangled in the process.

[Drew Lahat]

My point is that you’re both still wrong (as I was yesterday):

Chris, if you’re using “scale to fill” to maintain the “correct” aspect ratio (and crop the top&bottom), you’re giving your clients a slightly distorted image.

And Joe, your producers don’t notice anything is amiss because nothing is. Doing it wrong with Stretch to fill seems to be the only way to do it right…

Why? Because everyone’s display devices disregard the standards and apply an additional (or different) aspect ratio correction. If there’s a standard and all the displays ignore it in a consistent manner, well then I’ll ignore it too…
I’ll be happy to hear if I’m wrong about this.

[Drew Lahat]

Anyone with an XSAN 🙂 I helped support a few of those around L.A. back in 2007-2010, and while the LSI’s weren’t quite as good as the Atto’s, I don’t recall egregious issues with them. (Unlike OD binding, Promise array configuration scripts, and all that good stuff.)