Syme

Sounds like they have something to do with configuring video scaling filters. I highly doubt that there is actually a 4k mode, but modifying the configuration of the scaling filters could still be interesting. Where in the filesystem did you find these? Are you using an unpacked firmware upgrade .exe or examining the system through a remote terminal?

Hopefully it's somewhat obvious, but DON'T RUN THE BITRATE MODS ON THE NEW FIRMWARE UNTIL ON OF THE DEVELOPERS CHECKS IT OUT. It would probably do no worse than require a restart, but there is a very small chance it could do something nasty since the behavior is pretty much undefined at this point. Edit: I'm pretty sure the popular mods will refuse to install on the new version for now, but don't bypass that check.

There's nothing stopping someone from sending bayer RAW data over HDMI. You can send whatever data you want over HDMI, actually. It would appear as some crazy scrambled pattern to most HDMI devices, but the data would be there. Edit: I highly doubt they did that for this camera. Just saying it is possible.

Latest version includes telnet, which is great for exploring how the camera works. I really hope Sony doesn't crack down on this system in future firmware versions, but unfortunately they probably will.

Did it export really fast? Splitting without re-encoding should be about as fast as making a copy of the result. I don't know about MPEG Streamclip in particular, but that's a good way to tell in general.

I don't know. It's probably somewhat subjective what would be best for overall image quality. I'm not sure what a real log profile would do to macroblocking. The best settings for real usage will have to be determined by people actually using the camera.

There is no real hard limit to the bitrate of HEVC. Yes there is a maximum rate specified for each "level" of the standard, but that has nothing to do with the actual codec. What it really means is that all compatible HEVC decoders need to be able to decode at least 160mbit/s to meet the level 5.1 standard. That way any video that meets those specifications will play on any compliant decoder. It's a completely arbitrary number. No sane HEVC encoder cares about that part of the standard. It will happily spit out bits as fast as its algorithm and clock rate can keep up. The actual limit for a given piece of hardware or software depends on many things, but it almost certainly isn't exactly 160mbit/s. I hope that makes sense.

Here are my predictions for rolling shutter with the latest firmware: NX1 UHD: 32ms NX1 DCI: 30ms NX500 UHD & DCI: 19ms NX500 2.5k: 16ms NX1 & NX500 FHD 24-30p: 16ms or 11ms NX1 & NX500 FHD 50-60p: 16ms or 11ms NX1 FHD 100-120p: 8ms I'd love to see how close I am to the real numbers.

Yes, it could be impossible to turn off. The entire processing chain from sensor to H.265 bitstream could be done without any input from the software (except for selecting resolution and bitrate). I would bet money that it is possible to turn off noise reduction, since Samsung would be more than a little bit crazy to do it like that. However without proof it is still possible however improbable it might be.

Not impossible. Unlikely, but not impossible. It could be built into the HEVC encoder, for instance.

The "ASV Group" number is referring to one of a number of possible binnings of the chip, not the number of different voltages being specified. Two chips can have different ASVs and perform exactly the same, just with slightly different voltages. Take a look at http://www.anandtech.com/show/9146/the-samsung-galaxy-s6-and-s6-edge-review/2

Have you quantified any differences in the SoC itself? Apart from different version numbers the only differences I see are in memory (separate chip), audio codec (separate chip), and other board-level differences. Unless it's due to a lack of memory, as far as I can tell we still have no idea if there is a hardware reason (apart from power consumption) for the 4k crop on the NX500.

Their definition of "megapixels" seems a little bit fishy to me. I assume that means something like the number of samples used to measure the light field, but I'd rather know the size of the actual image it's going to create after turning the light-field into a 2D or 3D image. Seems like there must be a lot of "pixels" per actual pixel.

While in theory having a higher data rate means compressing less and compressing less requires less work that's definitely not the case in practice. I think it might be the case with software implementations of some codecs, but it is usually not true with dedicated hardware. I think it probably has to do with the fact that the codec in a camera has to guarantee a certain resolution and framerate regardless of how "difficult" the input is to compress. In other words, the codec isn't allowed to slow down if it has to compress more so the opposite is also true: the codec isn't allowed to speed up if it gets to compress less. The designers had to pick an algorithm to implement HEVC that was stable (w.r.t. changing input) at the cost of flexibility (and also an algorithm that is easy to implement in hardware). This may or may not be the main reason why the NX1 is behaving like it is, but it's important to understand. p.s. I hope that makes sense. I'm not a hardware codec designer, so correct/clarify if I'm wrong.

Nice! That's some of the first hard evidence we have about what's going on under the hood. Sounds like my pessimistic guess about the SRP was probably right. It makes the most sense for it to be used for what Samsung doesn't already have a more efficient IP block for (like SAS). I kind of wish that I, too, had a Samsung camera to play with. I spent most of spring break investigating my NEX 5t, but Sony goes to great lengths to keep people out of their products (at least compared to Samsung), which makes them no fun to work with.