1080p100, 4kp50 10-12 bits. Will this solution work?

Hi

I haven't bought a camera yet because it doesn't do 50p, which I want for more general purpose use. I have a number of possible solutions that could get around this:

Recording the display;
BM has mentioned problems with heating and getting compression to process more. But a live uncompressed display output does not require the compression engine, so could easily do 50p if the pott supports it. This live mode then can be recorded

Raw:
Another trick is that raw can be sent across HDMI at higher resolution/higher data rate, that can be transcoded latter to a regular format. HDMI can be regarded as a virtual multiplexed serial stream. So all that remains is to copy the image across into a suitable frame format that HDMI can transmit. If you look at it another way, Bayer will go pixel for pixel. so red channel can be one frame, green the second frame and blue the third frame, so 1080p60 gives 1080p180 Bayer.

The second idea is to output Raw uncompressed through another port at higher framerates. USB3/sata/tb can all be raid recorded to files.

The third is the easiest. At the moment flash data rates are increasing and there finally is crossbar technology coming through which is many times better and lower powered. 50p uncompressed Raw is then one day, probably now, recordable on single media. Even a raid/2 sd/ssd drive can be rigged up off the existing interface. All BM has to do is enable Raw uncompressed x frame rate '(experimental)' in firmware.

The fourth is to boost present compression/frame rate to 48p and 50p instead of 60p. 60p is not really needed. But as BM hasn't done this, I guess it is not possible.

Fifth, high speed low resolution. Lower resolutions versions/windowed(frame cutouts). Depending on sensor setup large frame rates are possible. Though not a cinema use, it has many other uses, such as research and sports clubs.


Thanks.

All your proposals assume that sensor and image processor are fast enough to support the functions you want - which they probably are not.

Depends on the camera, I'm pretty sure that either the original or 4k camera has 100fos sensor. Most of the suggestions avoid taxing various sections of the processing chain, but there can be just plain Data rate restrictions off chip preventing it, but all indications from statements made are it is not locked down to what it is outside of storage and compression. The low resolution windowing etc, is an old trick that should yield a lot, but there maybe maximum frame rate constrictions. The low resolution windowing works with existing data rates and compression by dividing the exist processing capacity by the lower resolution yielding a higher frame rate. I'm not clairvoyant to see everything, but from experience with camera development I can see what could be possible.

You seem to have made a great number of assumptions.

If I were to assume that everything in your post is accurate and practical you would still have one great boundary to overcome... and that is BMD itself. BMD has so far released very little in the way of updates for the BMCC (your post neglects to mention what camera you're referring to?) and when they do eventually start releasing updates it is logical that they will fix easy and important things first before eventually moving onto experimental issues (like audio metering, the inaccurate video LUT, in-camera formatting, etc.).

Furthermore, it would be great if they created a platform on which users could develop their own software/firmware mods for the camera (and SDK) but once again I would expect them to spend time on the easy/important stuff first.

But a live uncompressed display output does not require the compression engine, so could easily do 50p if the pott supports it. This live mode then can be recorded

You're assuming that the display in the camera is operating at 50p and that it is operating at Full HD in a sufficiently high bit-depth... given that the display only supports 800x600 and is probably linked using an embedded protocol like DSI the best resolution from this output would be limited by the display... and the inability of almost any device to capture the signal... among other issues. Oh and the camera's raw output is already uncompressed.

Bayer will go pixel for pixel. so red channel can be one frame, green the second frame and blue the third frame, so 1080p60 gives 1080p180 Bayer.

Illogical. Why would using four frames for every one frame increase the effective frame rate ? For 60p you'd get an effective rate of 15p. HDMI supports 4:4:4 sRGB, so assuming the camera could capture at 60p you could output at 60p via HDMI (or in the BMCC's case SDI). The camera only samples at 4:2:2, so the extra green photosites could be output as part of the remaining space of the red and blue frames.

Fifth, high speed low resolution. Lower resolutions versions/windowed(frame cutouts). Depending on sensor setup large frame rates are possible.

You're assuming that their sensors can operate like that and that their supporting components can operate like that... that's a big assumption, especially seeing as the camera has no existing SD or 720p modes.

You seem to have made a great number of assumptions.

Yes, that is the speculative nature of development, proposal conjecture then refinement. I also add a number of qualifiers to allow it not to be true. It is up to BMD to use their own inside knowledge to quantify if it is possible, this is only the start.

Assumption is also assuming that somebody is assuming. Credibly proving something is not possible is practical refinement.

>>If I were to assume that everything in your post is accurate and practical you would still have one great boundary to overcome... and that is BMD itself. BMD has so far released very little in the way of updates for the BMCC

This is loss leader time for BMD, when they do things to make market and reputation. So it is practical to listen and improve. I have caught them listening and bringing the improvements over to he design of the second series of cameras. They have been up against it though, with all the sensor issues to do with the first camera. and the low volumes. So significant update/changes to that camera are less justifiable.

They have said they have looked into things in the past, but I can assume for market reputation, they don't want dongles, out of standard tech fixes hanging off their cameras, and part solutions (they probably want to go to 60p for all markets than just 50p and have people ask where is 60p). Though I'm positively here to say it is good for some users, and if done right will enhance the cameras.

>>(your post neglects to mention what camera you're referring to?)

If you reread it you will notice I am deliberately covering any and all cameras, whichever suites a scheme, so some flexibility at this stage, otherwise you can kill any project dead. It helps if one can justify what they say to themselves before they post positive or negative.

>>and when they do eventually start releasing updates it is logical that they will fix easy and important things first before eventually moving onto experimental issues (like audio metering, the inaccurate video LUT, in-camera formatting, etc.).

Its logical that they do it all positively. but I suspect that we shall see most done in the new camera.

Furthermore, it would be great if they created a platform on which users could develop their own software/firmware mods for the camera (and SDK) but once again I would expect them to spend time on the easy/important stuff first.

To build reputation requires both. There us nothing easy about it.

But a live uncompressed display output does not require the compression engine, so could easily do 50p if the pott supports it. This live mode then can be recorded

>>You're assuming that the display in the camera is operating at 50p and that it is operating at Full HD in a sufficiently high bit-depth... given that the display only supports 800x600 and is probably linked using an embedded protocol like DSI the best resolution from this output would be limited by the display... and the inability of almost any device to capture the signal... among other issues. Oh and the camera's raw output is already uncompressed.

Your assuming a lot of things that I'm not. In the case of the pocket as one example the display output us HDMI, which generally supports a wide range of resolutions, a few frame rates, and many bit depths, and generally is programmable, even if just by selecting different modes. Also I have been specifying the range of cameras as the ones to look at, and the new ones do compressed raw. So display output (to external display) that some do compressed but could do uncompressed with future media, and that I'm talking about what can be done with the cameras that do compressed, is obvious and logical.

Bayer will go pixel for pixel. so red channel can be one frame, green the second frame and blue the third frame, so 1080p60 gives 1080p180 Bayer.

>>Illogical. Why would using four frames for every one frame increase the effective frame rate ? For 60p you'd get an effective rate of 15p. HDMI supports 4:4:4 sRGB, so assuming the camera could capture at 60p you could output at 60p via HDMI (or in the BMCC's case SDI).

Totally logical, it was explained how to get there Bayer frames into one 1080p60 4:4:4 frame yielding three times the framerate, not the reverse. As explained the section was about how to squeeze a number of Bayer frames into and over HDMI modes, also applicable to other display ports. I also mentioned they had to be unsqueezed back into a proper format. Some display output ports out there use primarily serial view of display data and the whole lot can be serialised as data rather than frames. Also, maybe a Bayer frame can be output inside of high frame rate monochrome frames in some display output technologies, but I am unsure if any support this (as being centrict and biased to existing standards they probably don't see the need for a 180fps 1080 monochrome mode. So this is a technical subject on how to squeeze Bayer over incompatible protocols.

Fifth, high speed low resolution. Lower resolutions versions/windowed(frame cutouts). Depending on sensor setup large frame rates are possible.

>>You're assuming that their sensors can operate like that and that their supporting components can operate like that... that's a big assumption, especially seeing as the camera has no existing SD or 720p modes.

I explained all this in there. Many sensors support what I'm talking about, even some very cheap cameras. High speed readout has even been used to overcome rolling shutter, by reading frames at 50-240th+ of a second and recording at 25-60p. From this side of the camera hardware a lot more things are obvious, especially from this side of design work, which is why I qualify my statements to allow for the possibility of things being different, not unqualified assumptions as I have been accused of. If you are using a translation service that might explain the problem. In something like this it is hard enough to read some reviews let alone intricate design considerations of technical ideas, which get difficult to follow around.

Now I've just woken up sick and out, making it difficult to reason, so sorry for the writing, I am rushing to a commitment as I'm picking up.


Thanks again Aaron.