Reasons for discontinuation of QSC CMS-5000

[Tacky Ting]

QSC CMS-5000 is more advanced in terms of hardware than other servers. Why did QSC make the decision to discontinue production?

[Leo Enticknap]

My understanding is that it was very similar, hardware wise, to the short-lived USL IMS, which itself was based on the IMB that was produced in significant numbers as the Dolby cat745.

Only QSC knows why they pulled the plug on it. My guess is that Dolby, GDC, and Barco already had an almost 100% market share of the server/media block market, and that QSC struggled to take any of that market share from them. Added to which, the QSC IMS only added any value relative to its competitors if there was already Q-Sys infrastructure in the booth, which limited the size of that potential market even further. Combine a very small potential customer base with the cost of developing and supporting this product over a likely ten-year lifespan, and I would speculate that QSC concluded that the math simply didn't add up.

[James Gardiner]

Being honest here. Cinema installs will be slow for the following years as the industry is in a contraction period as it comes to terms with the changing environment. With a new product like that, your main inroads are new customers. And as there will be a low level of new customers for the foreseeable future, and the incumbents are being as competitive as they can be to dominate the markets in this period.
I see no room for this product, especially now.
It is not cheap to keep up with the DCI requirements and potential bugs that do occur. Commercially it would be difficult to justify this product upkeep and development. I am surprised they even attempted. I would have advised them to focus on other issues as I expected the current market conditions. Covid just made it happen sooner.

[Leo Enticknap]

This thing was basically the USL CMS-2200 with (I understand) minor hardware tweaks and server side software to integrate it with Q-Sys. The initial R & D costs were therefore likely relatively low, and they were mainly leveraging IP that they acquired with the USL takeover. So I am not surprised that they attempted. But covid came along shortly after they launched it, and then all the economic headwinds you mention started to develop. I am therefore equally unsurprised that they pulled the plug.

As for Q-Sys, the APIs for the Dolby IMS3000 and Barco ICMP are freely available. There is already a third party Q-Sys plugin available for the IMS3000, and I've heard rumors that an official QSC one is about to drop, too. Anybody who wanted to achieve basic Barco ICMP functionality from within Q-Sys could do so relatively easily. So the CMS-5000's "killer app" (integration with Q-Sys) was never a unique selling point for very long, anyways.

[James Gardiner]

You bring up a good point about interoperability. Dolby/Barco, (even Qube) have easily accessible documents on the APIs. Making them easy to integrate with and more comfortable long term as once no longer supported, those documents are still easily to obtain. These are key factors, from my perspective, that especially made Dolby and Barco players do well.
GDC. I would encourage them to rethink their position on this. They do have some good integration technologies, but its a locked down black box.

For example, access to the GDC API is under NDA only and you cannot release any open-source software that can talk to GDC equipment (As it would breach the NDA).
Making any software that users can read the code and see how the API worked would breach. Its why cinema-catcher-app uses python that is encoded to binary .pyc files.

[Harold Hallikainen]

The CMS-2200 was a server board added to the IMB (that Dolby mostly sold). As I recall, both the IMB and CMS-2200 used a Power PC processor. The CMS-5000 was a substantial redesign that used a very fast quad core ARM. The CMS-2200 had a pair of DSPs just to watermark 16 channels. The CMS-5000 ARM could watermark 64 channels, do real time object rendering, etc. As I recall (and I only had a small part in its development), the quad core ARM handled SSD access, audio decryption, audio watermarking, network audio (QSYS), general network operation, etc. The ARM pulled video from the SSD and sent it to an FPGA for decryption, JPEG decoding, and watermarking. As I recall (and it's been more than 5 years since I saw one), the FPGA also handled the AES audio outputs and HDMI. I'm sure a lot of money went into its development. QSC largely dropped products specific to cinema (and I retired) in June 2020. I'd guess that it was cheaper to drop the product instead of continuing to invest in it and try to recover the investment through sales. It would have been interesting if they sold the design to another company, but perhaps other companies also did not see the profit potential in the product. Just guessing...

Here's the datasheet on the CMS-5000: https://www.qsys.com/resource-files/...5000_specs.pdf

[Tacky Ting]

I feel a pity because it can solve the problem of slow Ingesting Content, and I believe it will be very fast in operation.

[Leo Enticknap]

GDC. I would encourage them to rethink their position on this. They do have some good integration technologies, but its a locked down black box.

Which is why you wouldn't use a GDC product in an installation in which the server has to be commanded by an external device other than a TMS. In a typical multiplex setup this isn't an issue, and their lower price point relative to Dolby or Barco (which isn't an option anyways if a non-Barco projector is involved) gives them a competitive advantage there. But their refusal to share their API freely essentially rules them out as the first choice for arthouses, high end residence installs, screening rooms, etc.

[Steve Guttag]

GDC's position on their API (or just making a QSYS plugin...I'd rather they do it anyway) excludes them from most of my projects. I'm also non-jazzed about the encrypted logs. It isn't that they are not great at tech-support (they are and one of the best, at that) its that they are collecting data from someone that owns the equipment yet hides that data from them. With other servers, I can, often, more quickly assess the issue than waiting the time to sent a log up and get the results.

Make no mistake, the Barco ICMP, in all its forms, is directly tied it Barco's pricing of it when bought with a projector. When SDI based servers are failing due to age, how many are opting for the ICMP-X over Dolby or Barco? Likewise, to a lesser degree, for Christie and their various IMBs. Though, initially, they tied their lower-end machines to their fatally flawed server (IMB-S2).

The USL CMS series showed some promise with their UI...which seemed to really use the Dolby Show Manager as its inspiration. It would be nice if that sort of UI could be around as I don't like the current UIs nearly as much.

As to QSC/QSYS. They are a numbers driven company (yes, all companies are but this one really looks at near-future more than the long-game). So, when they made the decision to turn their backs on cinema, the big tell was the dropping of the CMS-5000. Then the dismissal of some notable people from the cinema division was it...even before discontinuing cinema-specific hardware. It wouldn't surprise me (and I have no inside information) that the failure of the CMS-5000, and its associated costs of acquisition/development didn't leave such a bad taste (financially) that QSYS didn't decide then and there to eject cinema as not being profitable enough. Where cinema does well is on channel count. We sell lots of amplifier channels and speakers. However, we are also thrifty. Who hasn't lost a sale over $50? That will tend to drive the overall $$$/channel down. That is something that QSYS, clearly, has no interest in.

Personally, I think there was a market for their CMS-5000 as both a QSYS product and as another 3rd party server. The original "box" servers with HDSDI have limited lifespans and they were/are needing to be replaced. That opens opportunities. Every QSYS product opens the door a bit further for their prized possession, QSYS (which is such a majority of what QSC does, QSYS stands as its own entity now). The CMS5000 would be almost, if not, unique in the QSYS family in that it could be used with or without QSYS. All other QSYS peripherals are designed around being operated by a Core. The amps can be put into standalone mode (if one has a Core to put them in that mode prior to deployment.

I don't know if QSYS, particularly as the company is now, would have the stomach/support for the CMS5000. Furthermore, this industry demands/needs perpetual support (e.g. not-Sony). You can't just put your toe in the water, get people to buy into your product and then think "nah...this isn't big/profitable enough) and pull up your carpet and leave.

If QSYS discontinues a speaker or amplifier or Core, it isn't the end of the world as there are alternatives and it won't greatly affect an existing installation or new one. You do that with a pricey piece like a server that changes your operation, people will be less likely to get involved with you again. It better make it to the 5-10 year mark.

Looking at the hard numbers...how much do you think it cost to develop a server/maintain it? What are the potential sales? I don't know the screen count but I believe it was around 175,000 screens, pre-covid. They were already cut up between existing servers. How many new-builds or encroaching of existing systems would they have had to make to justify the development? They would have almost had to have rationalized that, as a QSYS product, it would have helped drive the primary product, QSYS. That is, you put in a CMS-5000 and you put in a full QSYS system. It would have been more of a "foot-in-the-door" sort of product...yet have been one of the more expensive QSYS peripherals doing it. It also, unlike all of the other QSYS products, would have had a single use-case. Other than cinemas, who would use a CMS-5000? Even the DCIO-H can have A/V uses as it is still an analog, AES3 I/O box with some GPIO and HDMI decoding (the only QSYS product with HDMI decoding...there are some with LPCM only).

I would counter that a QSYS native product will always integrate easier/better than a typical plugin/user component. For one, it is upon QSYS to ensure that it "just works." Take amplifiers, as an example. You can use brands other than QSYS...but now you are going through a plugin and have to ensure you set things up just-so to use either AES67 (without redundant networking) or Dante (with all of its integration rules and yet another configuration device of Dante Controller). Or, put in a CX-Q (or other Q amp) and just plug it in. All of the integration is done/figured out. All of its inputs are generic mic/line inputs to be used as you please without anything needing to be configured. All with network redundancy (except on the smaller SPA-Q utility amps). The CMS5000 also had network redundancy...something that no other IAB processor has. Your entire sound system is hanging on a $2 patch cable. To this day, I put in a DCIO-H on all of my Atmos systems because AES3 is going to work and the DCIO has network redundancy. With the CMS5000, unless you need additional features of the DCIO-H (like the HDMI decoder), perhaps that isn't as needed and could count as a savings to the QSYS system using a CMS5000.

This is all speculation now, I do not foresee QSC/QSYS ever going down the cinema path again with cinema specific products. They will continue to trim the cinema specific product line based on recent sales until it is like it was before Barry Ferrell made QSC Cinema a thing...a company that makes products that may or may not have use to the cinema industry. Just like when I first started using them...things like the Model 1400 (series 1) amps. They were not made for cinema but cinema could use them...then the USA, the MX and EX amps that followed. I think we have Sam Chavez to blame for all of this. I think he chose QSC's series-1 amps for the Dolby packaged systems, of that era.

[Harold Hallikainen]

On API, I recall a lawsuit between Dolby and GDC. As I recall, it regarded GDC's TMS use of the Dolby server API. The suit was settled without going to trial.

[Steve Guttag]

Yes, that is how I remember it...it was settled. I remember thinking it was a <explicative> move by Doremi to withhold their API from a "competitor" because they wanted to incorporate ALL servers into the TMS system. People are treating the API like they are some holy jewels rather than a means to ask a device to do something (and/or get a status). It isn't like giving their source code for the product. If DCI wants to tweak things some...make DCI compliance require publishing ones API for interoperability . DCI was supposed to ensure that the theatre could choose whatever brand they wanted and everything should work together. The same goes for "licensing" to allow Brand A server working in Brand B projector. It's nonsense.

[Harold Hallikainen]

Long ago, there was a group working on such interoperability, but it apparently faded out. USL was part of the group.

[Sean McKinnon]

I have actually seen, installed, set-up, and operated, a CMS-5000. It was very promising, too bad they chose not to stick with it.

[James Gardiner]

I just want to bring up a costly issue with all DCI-Security managers, of which all playback and projectors have to have.
Typically you need an extremely secure area with expensive security access requirements. This must be maintained at all times. I.e. where the private certificates are created, stored and installed into the security managers. This area needs to exist and be operational for the life of the products... 10 years+, even if its is not making you money and more. It's a big investment. You have to be sure your going to reach critical KPIs in terms of sales.Right now, due to my software that tracks all active player certificates, the turnover of new players appears very slow at the moment. I have a tool coming that will be a one-stop shop for player certs for all vendor certificates or as much as is publically available.)

[Brad Miller]

Agreed with Sean, the CMS-5000 was a very promising product.

On the APIs, having an open API really should be part of DCI compliance. I would assume GDC is taking that stance of protecting it to try and force people to buy their entire line of products (sort of like Apple), but in the end I agree with the others here that they are actually LOSING business because there are lots of scenarios where it's just not an option. Keep in mind I say that as someone who (other than the encrypted logs and forced warranty purchases) is a fan of the SR1000.