Odyssey7Q April 2014 Firmware Update

[nyvz]

It can be frustrating, but would you guys actually prefer a rushed, buggy update or something solid that can be trusted on a pro shoot?

Not making excuses for these guys, but just putting a point across.

I get what you're saying but some people are annoyed because what we have had for months feels buggy and not that solid. So if its gonna be buggy anyway why not just add the features users expected.

Mitch has been very helpful and straightforward, but as much as engineering goals are understandably tough and out of his control, why then don't they promise to improve their engineering department? They are setting a poor precedent which may leave many consumers quite unconvinced of their ability to deliver advertised features which is a problem when a big selling point of their product is its future potential. This is part of the reason I sold my RED...

 

[Prendi]

I get what you're saying but some people are annoyed because what we have had for months feels buggy and not that solid. So if its gonna be buggy anyway why not just add the features users expected.

You beat me to it. Its not like the current firmware is flawless. Everyone that I work with (non camera types) says "that thing is really glitchy huh?". What can I say, it is. Point.

Trust me, if they had the firmware ready, with glitches or without, they would release it. Despite the fact that Mitch say "firmware update is less than a month away", they are simply miles behind. Who knows when they will fulfill their promises. Maybe never. Gemini.

 

[Prendi]

I just posted in another thread about this. The next firmware update will be in under a month (maybe a lot under) and while we are not sure what will make it in there, one thing we know will NOT make it is the 4K compressed codec.

Well, there's a surprise, it wasn't under a month and it certainly wasn't a lot under month. In fact, it's just over a month. So what's the excuse this time?

Looks like my timescale is more accurate than yours, Mitch.

 

[paolo.negro]

Ok guys, I totally share your frustration but we can't make our investment plan on promises (black magic docet).
We have to make decision on what is effective available, and in my opinion CD offer a huge enhancement to FS700 owners.
We don't have yet the announced features (what about onion skin, time-lapse etc… I can't see them in any new road map), but we should also remember that CD always said no chance for 4K raw but we have it!!!
Really can't wait for HFR proress, but till that moment we have so many lovely recording options and a great monitor.
Cheers
p.

 

[cckid]

give us a road map of future upgrades...and then stick to it...sounds so simple...but unfortunately it's not...maybe next week...right?

 

[rheinturmblau]

Well, expectations are rising. Broadcast Asia is over and the team should be safe home and settled. Time left, before IBC2014 in Amsterdam takes off.

In German, we have a saying: now it's the moment where the Elephant is passing water.

Keeping fingers crossed to see a significant progress...

soon.

 

[Prendi]

Well if Mitch said it's "soon", it must be true.

 

[Mitch Gross]

Hello Gentlemen, so god to be back after Broadcast Asia. I hope you don't mind that I took the weekend. It's a 23 hour flight home and that can take the socks out from under anyone. Plus I kinda wanted to see my kids a bit.

Anyway, I talked with our lead programming engineer today. He's feeling pretty good about the state of our next firmware update, but we did go over a couple of annoying glitches I noticed in the test build he sent me in Singapore (I told you guys that it would be worth it if you could stop by.). He believes that they can get things sorted out in a relatively few days.

And no, I will not make a prediction on just how few those days will be.

As soon as the engineers feel confident, the build goes into beta test phase, and then should be available about a week after that as long as the beta testers don't turn up anything horrendous. And that can happen -- it has pushed the firmware back to the engineers in the past. There are certain things that I or others have stated simply cannot be released and the engineers understood, took back the build and fixed it. This is the process, and it is like this everywhere. We're just a bit more public about it.

Be my guest to rail on me all you want. I'll suffer the slings and arrows, but it will not change the course of action. The engineers have to do their jobs, the beta testers theirs, and the rest of us ours. And when it is ready we will release.

There are features in the new build you will like. There are some which you may not care anything about, but others will. There is definitely substance to what will be coming. And then it is on to the next build.

 

[cinebuddy]

Well I own a BMCC, so I know a thing or two about waiting for firmware. Hell...I don't even know what I was waiting for update wise for my camera it's been so long. That said, I read this whole thread, and Mitch's willingness to discuss their process, and my own experience black holing the entire Internet into a T1 with a crappy BGP config, gave me the confidence to pull the trigger on one of these bad boys. I'm a Convergent man. I'm going to head out tomorrow and shoot some ish at 240fps, fill up my drives quickly and like it!

 

[paulcurtis]

Miraizon tell me that the codecs are QuickTime components that install into QuickTime. There are no FFMPEG installs etc, so unless I've missed anything, I don't think it's using that at all. Have you tried it yourself? I've not looked carefully for any gamma shifts. I certainly didn't notice anything but will have another look.

I tested these very carefully (bought them too), i found the quality massively lacking compared to real ProRes and Cineform, i sent the developers examples and comparisons - i hope they work some more on them, they indicated they might.

They macro block much earlier than real ProRes, in some cases IMHO shockingly so.

Also they claim that internally the data is always 10 bit YUV, AFAIK ProRes 4444 is 12 bit internally, certainly cineform 444 *is* 12 bit. So i don't think they're compatible from that perspective either.

I'm so surprised Apple hasn't gone after them for using ProRes so blatantly and in a way that isn't positive.

So test very carefully yourself.

cheers
Paul

 

[Pgale]

Hello Gentlemen, so god to be back after Broadcast Asia. I hope you don't mind that I took the weekend. It's a 23 hour flight home and that can take the socks out from under anyone. Plus I kinda wanted to see my kids a bit.

Anyway, I talked with our lead programming engineer today. He's feeling pretty good about the state of our next firmware update, but we did go over a couple of annoying glitches I noticed in the test build he sent me in Singapore (I told you guys that it would be worth it if you could stop by.). He believes that they can get things sorted out in a relatively few days.

And no, I will not make a prediction on just how few those days will be.

As soon as the engineers feel confident, the build goes into beta test phase, and then should be available about a week after that as long as the beta testers don't turn up anything horrendous. And that can happen -- it has pushed the firmware back to the engineers in the past. There are certain things that I or others have stated simply cannot be released and the engineers understood, took back the build and fixed it. This is the process, and it is like this everywhere. We're just a bit more public about it.

Be my guest to rail on me all you want. I'll suffer the slings and arrows, but it will not change the course of action. The engineers have to do their jobs, the beta testers theirs, and the rest of us ours. And when it is ready we will release.

There are features in the new build you will like. There are some which you may not care anything about, but others will. There is definitely substance to what will be coming. And then it is on to the next build.

Thanks for the update Mitch, much appreciated.

Have you decided on feature updates for each firmware rather than significantly quicker interim bug fixes? I thought the idea was to be able to release quick bug fixes especially for bugs introduced in newer firmware? Or was the decision based on the severity of the bugs? I.e. You don't feel the existing bugs are a show stopper?

thanks.

 

[Pgale]

I tested these very carefully (bought them too), i found the quality massively lacking compared to real ProRes and Cineform, i sent the developers examples and comparisons - i hope they work some more on them, they indicated they might.

They macro block much earlier than real ProRes, in some cases IMHO shockingly so.

Also they claim that internally the data is always 10 bit YUV, AFAIK ProRes 4444 is 12 bit internally, certainly cineform 444 *is* 12 bit. So i don't think they're compatible from that perspective either.

I'm so surprised Apple hasn't gone after them for using ProRes so blatantly and in a way that isn't positive.

So test very carefully yourself.

cheers
Paul

thanks for the heads up Paul. I've not gone into detail looking at the quality. I'll be aware of that.
Have you seen that miraizon have just released a new version just a week or two ago? Offhand, I don't know if any of your quality issues have been addressed though.

 

[paulcurtis]

thanks for the heads up Paul. I've not gone into detail looking at the quality. I'll be aware of that.
Have you seen that miraizon have just released a new version just a week or two ago? Offhand, I don't know if any of your quality issues have been addressed though.

I take another look and see. I believe the difference is the level of quality. ProRes is a DCT based codec, whereas Cineform is wavelet based. It's just that Mac ProRes looks higher quality than this version. So they may have just turned the quality slider to 11.

It's a bit off topic though, feel free to mail me if you need any info

cheers
Paul

 

[Prendi]

Hmm, you're doing better. At least this post is honest. Reading between the lines, you're saying - "The firmware isn't nearly finished and it's full of bugs. I have no idea when it will be released." This is progress IMO, as it sure beats another BS release date which is inevetibly missed.

 

[rheinturmblau]

Reading behind the lines, I guess Mitch is just cautious.

The developers always run the hamster wheel. It is important to lock a software development process from time to time to prepare beta tests and a release. Even if we should expect an intermediate software, still waiting for 4K compressed recording. May be it is our impact that there is a break to prepare that release now. It is getting more and more important to show progress after two months of waiting (and more waiting to go).

If we are heading for longer release cycles, CD should think about friendly user tests in the field, until the mission is completed. I guess we would be able to handle an use-at-own-risk-stupid! experimental version and a production-safe version, if upload stays easy as now. Other software companies release public betas, which speeds up bug-hunting and cheers up their community.

 

[Mitch Gross]

Thanks for the update Mitch, much appreciated.

Have you decided on feature updates for each firmware rather than significantly quicker interim bug fixes? I thought the idea was to be able to release quick bug fixes especially for bugs introduced in newer firmware? Or was the decision based on the severity of the bugs? I.e. You don't feel the existing bugs are a show stopper?

thanks.

I'm going to be painfully honest here, this current build took way too long. When we have a couple of known bugs we should get them fixed and release a patch. That was the plan here, with the idea to release such fixes as soon as a certain function we were finishing was ready. And then problems arose with that feature which spilled into other areas and delays occurred, etc., etc.

Here's how this train works. We release a firmware build, say 1.11.100. As soon as it is out the engineers are working on the next set of stuff, so now it's a new build, say 1.11.200 (I'm making up this number). They start adding bits here and there and changing thngs in various areas as they need to in order to make new functions work. Suddenly we get word of a problem in 1.11.100. Okay, we incorporate the fix into 1.11.200, but the code has already be unravelled in order to insert the new functions. So now they need to stitch it all back together again and hope it works. Of course it won't so the task now becomes the bug hunt to see what went wrong.

Every engineer is an optimist. They always think they can figure it out and get all the details sorted fairly straightforwardly. It's not just Convergent Design, it's in their nature. They are logical problem solvers. Unfortunately these things can often take way more effort than they anticipate. As we have all learned painfully here.

So what they really want to do at this point is fix 1.11.200. They want to move forward. What no one wants to do is drop 1.11.200 and move back to 1.11.100, fix the problems in there, hunt down the new bugs this will invariably create, and then release this as a patch. Because the fear is that this could take even longer to complete and it will most certainly delay the progress to new features.

So here's me sharing like I probably shouldn't share with you. We made the wrong call. We should have stopped, gone back, fixed the bugs and released a patch firmware. Then move forward with the new features. Because this has taken too long.

Our plan moving forward: We will release a new firmware, and then work will commense on the next firmware. But we will be prepared to stop if a bug is discovered which is considered significant and detrimental to shooting. We will fix it, releasea patch and then move on.

 

[Mitch Gross]

Hmm, you're doing better. At least this post is honest. Reading between the lines, you're saying - "The firmware isn't nearly finished and it's full of bugs. I have no idea when it will be released." This is progress IMO, as it sure beats another BS release date which is inevetibly missed.

Thanks, I guess. But I have always tried to be honest.

To be clear, the firmware is not "full of bugs", but there are issues remaining which is why it is not yet ready. But it is close.

I hate giving firm release dates because they can so easily be missed. There really is no way to predict these things. Every time I succumb to the pressure to give a date I later regret it. So yeah, y'all will know when it's ready 'cause I'll tell you "it's ready".

 

[Mitch Gross]

Reading behind the lines, I guess Mitch is just cautious.

The developers always run the hamster wheel. It is important to lock a software development process from time to time to prepare beta tests and a release. Even if we should expect an intermediate software, still waiting for 4K compressed recording. May be it is our impact that there is a break to prepare that release now. It is getting more and more important to show progress after two months of waiting (and more waiting to go).

If we are heading for longer release cycles, CD should think about friendly user tests in the field, until the mission is completed. I guess we would be able to handle an use-at-own-risk-stupid! experimental version and a production-safe version, if upload stays easy as now. Other software companies release public betas, which speeds up bug-hunting and cheers up their community.

We set a goal of getting certain functions completed. If other engineers were able to get their items done within the same timeframe they we would include it in the release as well. But as soon as we completed a handful of select functions then we would be ready to lock it down for release.

And no, we are absolutely not heading for longer release cycles. The goal is and has been to speed up our firmware releases. It's now been more than two months since our last release. Too long in my book.

 

[stefanvanjaarsveld]

Mitch,

Thank you for sharing this info and appreciate your openness. Good luck to the team with the work ahead!

 

[Pgale]

Thanks for the honesty Mitch, it really is appreciated and helps put my mind at rest, even if there are daily struggles with bugs and quirks.

It it sounds like you need an even more intense beta / bug squashing phase. Or maybe even a public beta where many people represented here would be more than happy to help out by testing. I know there's always the risk of someone using a beta on a live shoot and coming unstuck, no matter how much you say the beta shouldn't be used as such - maybe a beta could have a watermark to prevent that. I know I'd still be happy to test even if I couldn't use it in production.

Given that some of the current bugs are very obvious from the moment the firmware is installed, I wonder how many of your beta testers are actually testing properly? Just a thought.

On the topic of bugs, I was shooting over the last week and noticed a couple more bugs that I'd not noticed before. I'll report them to support but wanted to know if others have seen these too:

1) focus assist mode in 4K2HD - the focus overlay is offset way to the left, not over the live image.
2) after stopping a record and then quickly starting again, the red record bar at the top of the O7Q screen isn't drawn properly, just some blocks of red.
3) pressing the hide button whilst recording, hides the controls but there's no way to get them back again until recording is finished.

I can provde screen shots or videos if needed.

Probably known bugs. BTW- is there a known bug list anywhere (on your web site)? That would be very useful.

Thanks,

paul.