Odyssey 7Q Firmware 2.11.110

hambulance said:
Hi Mitch,

I thought I would ask here rather than make a new thread.

A couple O7Q questions:

1. What is the possibility (or likelihood) of running Cineform as a compression codec, especially since it has been now standardised by SMPTE? (eg. http://news.doddleme.com/blogs/post-production/gopros-cineform-codec-adopted-as-new-smpte-standard/). Is this on the CD radar, and would this be added to the roadmap if it is not already?

2. Also is a vectorscope coming soon?

:)

Cheers.
Click to expand...
#1
Thought I answered this before. Not gonna happen. To do this, the RAW file would have to come into the Odyssey7Q, be deBayered and turned into video from data, then re-compressed into Cineform. This would all have to happen in realtime and never have any artifacting in the process. And even if that could happen consistently it would have to not introduce any artifacts into the signal. That's not a likely proposition. If there was effectively two two Odyssey7Qs in the box working in parallel then maybe, but there's still the danger of the compression/decompression/recompression artifacting. There's actually a name for this compounding issue, concatenation.

#2
The vectorscope is coming soon! We've been planning out re-fresh of the menu structure as we add new features and determining how and where this would be implemented has been all worked out.
 
Oleksiy Oliks Kardash said:
When the deleting the desired clips internal - in O7Q - will be possible? Removing files only by formatting entire drive looks a little bulky and inconvenient.
Click to expand...
Answer:

No,
the Odyssey7/7Q does not record clips like ordinary operating systems. It needs to be capable to write with reliable speed to avoid loosing footage during high frame rate recordings. Therefore it fills up the SSD in one round and does not check for gaps, opened by deleted clips.
Mitch Gross said:
...we also cannot fragment an SSD by erasing frames. Not if you want a device that can record high speed, or 4K, or a lot of other things
Click to expand...
Checking for potentially defragmanted disk space during recording would add an additional process to the FGA processor and would slow down the device. And we want that Buddy run fast, very fast, to get all the missing codecs and their flavors, e.g. ProRes 4K at 60 fps.

This is important to understand in day-to-day use:
If you eject the SSD, it organizes its filetable to be accessible for PCs and Macs. But you should access the SSDs in a read-only-manner. After your project is done, clean up by reformatting the SSDs.

Of course, it's bulky during post production/editing, but this keeps the little O7Q-hamster inside spinning the wheel as fast as possible on set.
 
Last edited:
AIUI It makes no difference to an SSD where it stores files, whether contiguous or fragmented all over the place. There is some talk that seriously fragmented SSDs might have a barely imperceptible sequential read/write performance penalty but no where near levels of spinning disks. At least that's what I understand from my research.

after my shoot on location this week, I for one would definitely welcome a delete option on the O7Q if it was possible.
 
No, the SSDs do not care, which part is written.
But you need a process to allocate space, so existing content is not overwritten by new recordings. And the device needs to organize tables to track clips for playback. Parts of these tasks have to be managed by the O7Q Firmware, not the SSD-Hardware. Today, this is coded very lean and simple. Additional payload for the FGA processors is low. That's in our all interest.

I do not understand your priorities.
Top priority should be performance during recording.
And getting a set of reliable Codecs for recording.
We still miss important features.
One very obvious point is the need to optimize the payload already.
That's the reason why 1080p50/60 was behind 1080p24/25/30 and why we just get 2160p24/25/30 next week or the week after.

If de-bayering 4K frames and compressing them using ProRes HQ codec is demanding for our O7Q units, why add additional complexity? We do not even know, if CD is able to handle ProRes HQ 2160p50/60. It might come or it might not come.

If the device would be running at 50% performance in all modes only, I would definetly vote to add comfort. If we are needing 90% something already to write sequential files of compressed clips, do not touch. CD is free to implement that later, after the core recording modes are available and rock-solid.
 
Last edited:
Oleksiy Oliks Kardash said:
When the deleting the desired clips internal - in O7Q - will be possible? Removing files only by formatting entire drive looks a little bulky and inconvenient.
Click to expand...
As stated previously, this is not possible. To do so would mean fragmenting the SSD. This lowes speed performance, so we don't do it no matter what format you choose. I had the same issue back in my hantom days, but it is what you must live with if you want high performance.
 
Folks, fragmenting lowers performance. It effects things in the SSD as well as the communications with it. I'm sorry if you do not believe this is true, but it is.
 
I understand that a ridiculous file structure is necessary for recording ridiculously large files, but the product reallt suffers in usability and convenience because of it. Once we have prores i'd really like the option of a filestructure that doesn't have to be brought back to the 7q and rewritten just to be readable in an actual computer. Or run through an extremely limted proprietary app just to give you your media in a useable format. That's two extra annoying steps you don't have to do on other similar less expensive recording products. Couldn't you have the computer utility be capable of fixing the file table or reading the unfixed file tables? I just know people are going to shoot their SSDs and then power down the unit and send their SSD to dump somewhere they won't have immediate access to the 7Q and all their files will appear to be missing because they didn't run the eject operation before powering down...

And please get exfat please! Being heavily dependent on proprietary computer utilities just to make footage useable and to overcome limitations of fat32 really weaken the whole workflow, and it all seems extemely avoidable! Why the heck would anyone ever use fat32 for any application that by nature uses >32GB volumes and >4gb files??
 
Last edited:
Pgale said:
AIUI It makes no difference to an SSD where it stores files, whether contiguous or fragmented all over the place. There is some talk that seriously fragmented SSDs might have a barely imperceptible sequential read/write performance penalty but no where near levels of spinning disks. At least that's what I understand from my research.
Click to expand...

Based on my years of experience in developing flash memory-based products, I have to say yes it DOES make a difference.

Flash is obviously electronic, no moving parts, etc. But it's not anywhere near as simple as RAM (which itself isn't actually near as simple as it seems). With flash, you have a LARGE section of the storage buffered in RAM inside the SSD (or SD card, XQD, whatever), which gets written in one big block when you hit the end of it. If you start jumping all over the place -- as you would on a filesystem where files had been deleted to make space -- then you have to start dumping and re-loading the RAM buffer long before it's full. Flash is fast, but it's a lot slower than RAM, and writing flash in particular is SLOW. So this jumping around would hurt overall performance, but more importantly would introduce "glitches" where it hesitates for a few ms every so often -- and then you're dropping frames.

I've personally benchmarked SD cards for consumer products, and seen the performance MASSIVELY PLUMMET when you start doing random, as opposed to strictly sequential, accesses. It's a big deal. How big a deal depends on the architecture of the stuff inside the drive/card -- the controller, the RAM buffers, how parallel the access to the actual flash is, etc. In other words the stuff behind the impressive sticky label. It's not just flash in there, folks, it's a whole computer. This is why it makes sense to me to use SSDs, XQDs, and the like for high-bitrate video; they have more powerful controllers and more RAM to deliver more consistent performance. Not faster -- more consistent.

You can test this easily enough, BTW (with a little coding skill). Write an app which does sequential writes to a clean SD card; and another which does random writes (create a huge file and write random blocks in it). You'll see the performance difference.

Obviously this isn't an issue at low bit rates; SD-based cameras (mostly) work just fine. But the 7Q isn't dealing with low bit rates, it's pushing something like 3 Gb/sec? Which is stressing the performance of the flash to the limit.

rheinturmblau said:
... the Odyssey7/7Q does not record clips like ordinary operating systems. It needs to be capable to write with reliable speed to avoid loosing footage during high frame rate recordings. Therefore it fills up the SSD in one round and does not check for gaps, opened by deleted clips.
Click to expand...

I'm quite impressed by this; CD have done their homework. Yes, this makes it a little more inconvenient to use, but it's this kind of thing that gets you beyond impressive numbers on the sticky label, and to performance that delivers RELIABLY in the field.
 
1st world problems...

nyvz said:
I understand that a ridiculous file structure is necessary for recording ridiculously large files, but the product reallt suffers in usability and convenience because of it. Once we have prores i'd really like the option of a filestructure that doesn't have to be brought back to the 7q and rewritten just to be readable in an actual computer. Or run through an extremely limted proprietary app just to give you your media in a useable format. That's two extra annoying steps you don't have to do on other similar less expensive recording products. Couldn't you have the computer utility be capable of fixing the file table or reading the unfixed file tables? I just know people are going to shoot their SSDs and then power down the unit and send their SSD to dump somewhere they won't have immediate access to the 7Q and all their files will appear to be missing because they didn't run the eject operation before powering down...

And please get exfat please! Being heavily dependent on proprietary computer utilities just to make footage useable and to overcome limitations of fat32 really weaken the whole workflow, and it all seems extemely avoidable! Why the heck would anyone ever use fat32 for any application that by nature uses >32GB volumes and >4gb files??
Click to expand...
 
vcfilms said:
Looks like we'll be waiting until the end of the month for the 4k Pro Res update?
Click to expand...
rheinturmblau said:
IBC 2014 is over,
no booth at Photokina 2014 Cologne.

They should be back at home, hugging kids and dogs this weekend.
Click to expand...
IBC over, weekend over, kids and dog happy,
what a nice September week to share happiness with customers.

Ladies, Gentlemen, please roll out the Firmware.
Looking at a perfect 4K ProRes-Shooting location this moment!
 
Last edited:
You must log in or register to reply here.
Back
Top