Syme

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.

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.

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.

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.

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

I don't think I currently have the experience or time to successfully modify the NX1/NX500 firmware. I don't even have one of those cameras. However it would be a shame to let the interest in this die, so I guess I'll post some of my notes/thoughts about the firmware in hopes that it might help keep the ball rolling.
Note: if you aren't into technical minutiae, the only interesting part of this wall of text is the bulleted list at the end detailing what is and is not possible in my opinion.
Here are the files listed in the header of nx1.bin (version 1.4.0):
version.info:    offset=0x0          size=0x3F   (same as found in /etc/version.info)
linux image:    offset=0x0130       size=0x00624748
idk:                   offset=0x624878     size=0xD8E9
linux image:    offset=0x632161     size=0x3192E8
linux image:    offset=0x94B449     size=0x638518
idk:            offset=0xF83961     size=0x01FF10
idk:            offset=0xFA3871     size=0xB35140
rootfs:         offset=0x1AD89B1    size=0x117A89FF     (lzo compressed ext4 filesystem image)
opt:            offset=0x132813B0   size=0x58E91C   (lzo compressed ext4 filesystem image)
pcachelist:     offset=0x1380FCCC   size=0x7000 (PAGECACHELIST, preceded by a header, I think)
idk:            offset=0x13816CCC   size=0x35BCC44  (lzo compressed. header indicates swap image?)
Anyone with the skills to reverse engineer a camera could figure this out pretty easily, but it was fairly tedious so maybe this will save someone 20 minutes of poking around in a hex editor. If anyone knows what's up with the files I've labeled "idk," I would love to hear about it.
The checksum algorithm is fortunately unchanged from the NX300 as far as I can tell.
As documented at sites.google.com/site/nxcryptophotography/diy-firmware
"width=32 poly=0x04c11db7 init=0xffffffff refin=true refout=true xorout=0x00000000 check=0x340bc6d9 name="JAMCRC""
"jacksum -x -a crc:32,04c11db7,ffffffff,true,true,00000000 [file]"
The main camera app binary is (I'm pretty sure) located at /usr/apps/com.samsung.di-camera-app/bin/di-camera-app in the rootfs. It seems to access the hardware through a relatively high-level API with the /usr/lib/libmm* libraries. libmmf-camcorder.so is particularly interesting. The function I've focused my attention on is mmf_camcorder_set_attributes(), which comes from libffm-camcorder and is used repeatedly in di-camera-app. It conveniently (and strangely IMO) takes strings as identifiers for the attributes that are apparently being set (why not just an enum? I suppose I shouldn't look a gift horse in the mouth...). Some of those attributes include "target-time-limit," "audio-encoder-bitrate," and "video-encoder-bitrate." The guy who successfully removed the recording time limit on the NX300 did it by modifying the instructions that set the variable being passed along with "targe-time-limit." I found the control flow instructions he mentioned in that thread, so it should't be hard to get rid of the time limit on the NX1, provided the camera accepts the modified firmware. The NX500 is probably similar. The "video-encoder-bitrate" attribute also looks promising, though it would take some more advanced reverse engineering to figure out where the values are being set.
So from what I've seen and read, here is what I think is and is not possible to modify on the NX1 and NX500:
Remove time limit: Highly likely. Seems to be the same as the NX300. Pretty easy too, if there aren't any new security measures in place. Increased bitrate: Possible. Needs some real reverse engineering to find where the rates are set for each resolution and quality. Noise reduction and sharpening: Possible. Haven't seen anything that looks like it's controlling these, but if setting the bitrate works, this should be possible too. FWIW I think that increasing the bitrate would help with the noise reduction issues. H.265 tends to smooth things out a lot to achieve low bitrates. Re-enable 2.5k on NX500: Plausible but difficult. It depends on whether they just removed it from di-camera-app, or if they removed it from the underlying libraries as well. Either way it would likely require actually adding control flow to the binary, which opens a whole new can of worms. Beyond my current ability, for sure. Focus peaking for NX500 4k: Maybe? I have no idea, really. There might be a good reason they didn't include it, there might not. 4k crop on NX1: Plausible but even more difficult. We know the hardware can do it, but it was probably never implemented on the NX1, even in pre-production. Gamma profile on NX500: Plausible. Similar to porting the NX500's 4k crop to the NX1, I think. 6k 24fps H.265: Highly unlikely. The H.265 encoder would have to support frame sizes larger than DCI 4k and be able to handle twice the pixel rate (clock speed) of 4k. Furthermore it would require implementing a brand-new video mode at a very low level. I can't say for sure it's categorically impossible, but don't get your hopes up. 10bit H.265: Nope. The H.265 standard does indeed allow for 10bit encoding, but I highly doubt Samsung would include the significantly larger (wider busses, more complex encoding) hardware necessary to do it. It would be a miracle if Samsung had really decided to go to all that effort and not use it. 6k or full sensor 4k at more than 30fps or 1080p at (significantly) more than 120fps: Impossible. The image sensor simply isn't fast enough. If you hope for this you will just be disappointed! RAW Video: Not really. It might be theoretically possible to dump the live-view feed as in Magic Lantern. Who knows how fast the SD card interface is, though. Certainly no more than 1080p. I can imagine tricking the GPU into packing 12bit 4k RAW into 1080p 444 HDMI like Apertus, but consider that a pipe dream. Don't get your hopes up. Anyway, that was longer than I expected, but I enjoyed poking around in the firmware, so I don't regret it even if it comes to nothing. It's a shame Samsung appears to be dropping the NX line; they are cool little cameras.
p.s. If you know anything I've said is wrong, please correct me; I'm learning this as I go along.

I don't think he has claimed to have proved that the CPU is different. It would be foolish for anyone to claim to know if the SoCs are the same or different without proof.
The possible differences between the SoC in the NX1 and the one in the NX500 will not necessarily appear in the source code that Samsung has released. The same source code can work with different hardware depending on how it is configured. What's more, there are probably (well, almost certainly) binary-only firmware blobs that are uploaded to run certain parts of the SoC that aren't directly controlled by the kernel. The kernel doesn't even have to include all the drivers needed to run the hardware. For all I know they might be using a user-space driver or proprietary kernel modules for some components, which would not appear in the GPL-required source. Or they might not. But you would have to carefully analyze the entire firmware image to find out.
There are many possibilities at this point. The silicon could be identical and fully enabled in both chips. It could be identical and configured differently by low-level binary firmware. It could be identical but with parts permanently (laser) disabled. It could be different.
As far as I know it isn't possible to tell apart those four (or more I haven't thought of) cases for sure just based on kernel code. Or it might be possible to prove. All we know right now is that the CPU cores themselves are functionally equivalent, which doesn't really matter anyway.
If anyone knows that I'm wrong, please correct me. I'm somewhat familiar with embedded Linux, but I'm not an expert by any stretch of the imagination.

I kind of hope you're trolling, but I feel compelled to respond anyway.
tl;dr: Nobody has been making any implied promises, and your suggestion had already been tried and failed before you posted it.
First of all, nobody is claiming to be working on super-duper secret projects. Everyone has been very clear that they are doing this for fun in their spare time. From what I have read, nobody is releasing much since there isn't much interesting to release. For what it's worth, there have already been results, in particular from Otto and Vasile. Both of them made no promises yet delivered exactly what they said they expected to do. Vasile claimed to have found how to increase the bitrate, and provided a video as proof. Yea he could theoretically have faked it, but I see know reason to think that at this point. Otto stated his intentions very clearly and his results have already proven useful to people who want to take videos of events longer than 30 minutes (as well as anyone who wants to investigate their camera further).
You got radio silence on your suggestions because people were already working on that and ran into problems that you did not address at all. In case it's too much trouble for you to actually read what people have already written, the issue was that if the camera app is killed it freezes the camera. It's hard to replace an app if you cannot even remove it. If you think you know how to prevent that, I would love to hear it. If you want "traction" in this discussion, try actually being helpful.
Regarding the DRIMeV SoC itself, I mostly agree with your educated guess. It is almost certainly the same die, and the ARM cores are 100% identical. Unfortunately that's not saying much at all since most modern ARMv7 cores are identical as far as the software is concerned. It's the details of other blocks that would determine whether or not the important components of the camera application run or not. I can't tell just from skimming the kernel source code.
It takes under 5 minutes to find and download the firmware update from Samsung's site. If you really don't have 5 free minutes in your life, I don't understand why you are wasting time criticizing people who have actually accomplished things and posted them here. If you are 1/2 as smart as you make yourself sound, it should take you less than an hour to unpack all the components of the firmware. I had never unpacked a firmware before, but it only took me two evenings to get all the major pieces out. The offsets, sizes, compression, and filesystems are almost all documented right here in this forum, so there is no excuse not to take a look if you really want to test an idea.
I totally agree that the ratio of people waiting with high expectations to the people working on it is rather high. The Magic Lantern forums are just like that on a larger scale, but that doesn't change what they have or have not done. You need to keep in mind that this forum is a community of filmmakers, not hackers (or even "photographers"). The point of this thread in the first place was to show interest in modifying a camera, at which I'd say it has admirably succeeded!
Finally, nobody cares that you're a busy person. So you like your HoloLens and want to play with it. Cool story. We're all busy people too, so suck it up and either contribute or go back to lurking. Sorry for the tone, but that's because I can never stand people who drop into discussions and claim that they could do it all better if they didn't have so many more important things to do, yet don't contribute anything useful.
/rant

I don't think he has claimed to have proved that the CPU is different. It would be foolish for anyone to claim to know if the SoCs are the same or different without proof.
The possible differences between the SoC in the NX1 and the one in the NX500 will not necessarily appear in the source code that Samsung has released. The same source code can work with different hardware depending on how it is configured. What's more, there are probably (well, almost certainly) binary-only firmware blobs that are uploaded to run certain parts of the SoC that aren't directly controlled by the kernel. The kernel doesn't even have to include all the drivers needed to run the hardware. For all I know they might be using a user-space driver or proprietary kernel modules for some components, which would not appear in the GPL-required source. Or they might not. But you would have to carefully analyze the entire firmware image to find out.
There are many possibilities at this point. The silicon could be identical and fully enabled in both chips. It could be identical and configured differently by low-level binary firmware. It could be identical but with parts permanently (laser) disabled. It could be different.
As far as I know it isn't possible to tell apart those four (or more I haven't thought of) cases for sure just based on kernel code. Or it might be possible to prove. All we know right now is that the CPU cores themselves are functionally equivalent, which doesn't really matter anyway.
If anyone knows that I'm wrong, please correct me. I'm somewhat familiar with embedded Linux, but I'm not an expert by any stretch of the imagination.

I kind of hope you're trolling, but I feel compelled to respond anyway.
tl;dr: Nobody has been making any implied promises, and your suggestion had already been tried and failed before you posted it.
First of all, nobody is claiming to be working on super-duper secret projects. Everyone has been very clear that they are doing this for fun in their spare time. From what I have read, nobody is releasing much since there isn't much interesting to release. For what it's worth, there have already been results, in particular from Otto and Vasile. Both of them made no promises yet delivered exactly what they said they expected to do. Vasile claimed to have found how to increase the bitrate, and provided a video as proof. Yea he could theoretically have faked it, but I see know reason to think that at this point. Otto stated his intentions very clearly and his results have already proven useful to people who want to take videos of events longer than 30 minutes (as well as anyone who wants to investigate their camera further).
You got radio silence on your suggestions because people were already working on that and ran into problems that you did not address at all. In case it's too much trouble for you to actually read what people have already written, the issue was that if the camera app is killed it freezes the camera. It's hard to replace an app if you cannot even remove it. If you think you know how to prevent that, I would love to hear it. If you want "traction" in this discussion, try actually being helpful.
Regarding the DRIMeV SoC itself, I mostly agree with your educated guess. It is almost certainly the same die, and the ARM cores are 100% identical. Unfortunately that's not saying much at all since most modern ARMv7 cores are identical as far as the software is concerned. It's the details of other blocks that would determine whether or not the important components of the camera application run or not. I can't tell just from skimming the kernel source code.
It takes under 5 minutes to find and download the firmware update from Samsung's site. If you really don't have 5 free minutes in your life, I don't understand why you are wasting time criticizing people who have actually accomplished things and posted them here. If you are 1/2 as smart as you make yourself sound, it should take you less than an hour to unpack all the components of the firmware. I had never unpacked a firmware before, but it only took me two evenings to get all the major pieces out. The offsets, sizes, compression, and filesystems are almost all documented right here in this forum, so there is no excuse not to take a look if you really want to test an idea.
I totally agree that the ratio of people waiting with high expectations to the people working on it is rather high. The Magic Lantern forums are just like that on a larger scale, but that doesn't change what they have or have not done. You need to keep in mind that this forum is a community of filmmakers, not hackers (or even "photographers"). The point of this thread in the first place was to show interest in modifying a camera, at which I'd say it has admirably succeeded!
Finally, nobody cares that you're a busy person. So you like your HoloLens and want to play with it. Cool story. We're all busy people too, so suck it up and either contribute or go back to lurking. Sorry for the tone, but that's because I can never stand people who drop into discussions and claim that they could do it all better if they didn't have so many more important things to do, yet don't contribute anything useful.
/rant

I kind of hope you're trolling, but I feel compelled to respond anyway.
tl;dr: Nobody has been making any implied promises, and your suggestion had already been tried and failed before you posted it.
First of all, nobody is claiming to be working on super-duper secret projects. Everyone has been very clear that they are doing this for fun in their spare time. From what I have read, nobody is releasing much since there isn't much interesting to release. For what it's worth, there have already been results, in particular from Otto and Vasile. Both of them made no promises yet delivered exactly what they said they expected to do. Vasile claimed to have found how to increase the bitrate, and provided a video as proof. Yea he could theoretically have faked it, but I see know reason to think that at this point. Otto stated his intentions very clearly and his results have already proven useful to people who want to take videos of events longer than 30 minutes (as well as anyone who wants to investigate their camera further).
You got radio silence on your suggestions because people were already working on that and ran into problems that you did not address at all. In case it's too much trouble for you to actually read what people have already written, the issue was that if the camera app is killed it freezes the camera. It's hard to replace an app if you cannot even remove it. If you think you know how to prevent that, I would love to hear it. If you want "traction" in this discussion, try actually being helpful.
Regarding the DRIMeV SoC itself, I mostly agree with your educated guess. It is almost certainly the same die, and the ARM cores are 100% identical. Unfortunately that's not saying much at all since most modern ARMv7 cores are identical as far as the software is concerned. It's the details of other blocks that would determine whether or not the important components of the camera application run or not. I can't tell just from skimming the kernel source code.
It takes under 5 minutes to find and download the firmware update from Samsung's site. If you really don't have 5 free minutes in your life, I don't understand why you are wasting time criticizing people who have actually accomplished things and posted them here. If you are 1/2 as smart as you make yourself sound, it should take you less than an hour to unpack all the components of the firmware. I had never unpacked a firmware before, but it only took me two evenings to get all the major pieces out. The offsets, sizes, compression, and filesystems are almost all documented right here in this forum, so there is no excuse not to take a look if you really want to test an idea.
I totally agree that the ratio of people waiting with high expectations to the people working on it is rather high. The Magic Lantern forums are just like that on a larger scale, but that doesn't change what they have or have not done. You need to keep in mind that this forum is a community of filmmakers, not hackers (or even "photographers"). The point of this thread in the first place was to show interest in modifying a camera, at which I'd say it has admirably succeeded!
Finally, nobody cares that you're a busy person. So you like your HoloLens and want to play with it. Cool story. We're all busy people too, so suck it up and either contribute or go back to lurking. Sorry for the tone, but that's because I can never stand people who drop into discussions and claim that they could do it all better if they didn't have so many more important things to do, yet don't contribute anything useful.
/rant

I kind of hope you're trolling, but I feel compelled to respond anyway.
tl;dr: Nobody has been making any implied promises, and your suggestion had already been tried and failed before you posted it.
First of all, nobody is claiming to be working on super-duper secret projects. Everyone has been very clear that they are doing this for fun in their spare time. From what I have read, nobody is releasing much since there isn't much interesting to release. For what it's worth, there have already been results, in particular from Otto and Vasile. Both of them made no promises yet delivered exactly what they said they expected to do. Vasile claimed to have found how to increase the bitrate, and provided a video as proof. Yea he could theoretically have faked it, but I see know reason to think that at this point. Otto stated his intentions very clearly and his results have already proven useful to people who want to take videos of events longer than 30 minutes (as well as anyone who wants to investigate their camera further).
You got radio silence on your suggestions because people were already working on that and ran into problems that you did not address at all. In case it's too much trouble for you to actually read what people have already written, the issue was that if the camera app is killed it freezes the camera. It's hard to replace an app if you cannot even remove it. If you think you know how to prevent that, I would love to hear it. If you want "traction" in this discussion, try actually being helpful.
Regarding the DRIMeV SoC itself, I mostly agree with your educated guess. It is almost certainly the same die, and the ARM cores are 100% identical. Unfortunately that's not saying much at all since most modern ARMv7 cores are identical as far as the software is concerned. It's the details of other blocks that would determine whether or not the important components of the camera application run or not. I can't tell just from skimming the kernel source code.
It takes under 5 minutes to find and download the firmware update from Samsung's site. If you really don't have 5 free minutes in your life, I don't understand why you are wasting time criticizing people who have actually accomplished things and posted them here. If you are 1/2 as smart as you make yourself sound, it should take you less than an hour to unpack all the components of the firmware. I had never unpacked a firmware before, but it only took me two evenings to get all the major pieces out. The offsets, sizes, compression, and filesystems are almost all documented right here in this forum, so there is no excuse not to take a look if you really want to test an idea.
I totally agree that the ratio of people waiting with high expectations to the people working on it is rather high. The Magic Lantern forums are just like that on a larger scale, but that doesn't change what they have or have not done. You need to keep in mind that this forum is a community of filmmakers, not hackers (or even "photographers"). The point of this thread in the first place was to show interest in modifying a camera, at which I'd say it has admirably succeeded!
Finally, nobody cares that you're a busy person. So you like your HoloLens and want to play with it. Cool story. We're all busy people too, so suck it up and either contribute or go back to lurking. Sorry for the tone, but that's because I can never stand people who drop into discussions and claim that they could do it all better if they didn't have so many more important things to do, yet don't contribute anything useful.
/rant

I kind of hope you're trolling, but I feel compelled to respond anyway.
tl;dr: Nobody has been making any implied promises, and your suggestion had already been tried and failed before you posted it.
First of all, nobody is claiming to be working on super-duper secret projects. Everyone has been very clear that they are doing this for fun in their spare time. From what I have read, nobody is releasing much since there isn't much interesting to release. For what it's worth, there have already been results, in particular from Otto and Vasile. Both of them made no promises yet delivered exactly what they said they expected to do. Vasile claimed to have found how to increase the bitrate, and provided a video as proof. Yea he could theoretically have faked it, but I see know reason to think that at this point. Otto stated his intentions very clearly and his results have already proven useful to people who want to take videos of events longer than 30 minutes (as well as anyone who wants to investigate their camera further).
You got radio silence on your suggestions because people were already working on that and ran into problems that you did not address at all. In case it's too much trouble for you to actually read what people have already written, the issue was that if the camera app is killed it freezes the camera. It's hard to replace an app if you cannot even remove it. If you think you know how to prevent that, I would love to hear it. If you want "traction" in this discussion, try actually being helpful.
Regarding the DRIMeV SoC itself, I mostly agree with your educated guess. It is almost certainly the same die, and the ARM cores are 100% identical. Unfortunately that's not saying much at all since most modern ARMv7 cores are identical as far as the software is concerned. It's the details of other blocks that would determine whether or not the important components of the camera application run or not. I can't tell just from skimming the kernel source code.
It takes under 5 minutes to find and download the firmware update from Samsung's site. If you really don't have 5 free minutes in your life, I don't understand why you are wasting time criticizing people who have actually accomplished things and posted them here. If you are 1/2 as smart as you make yourself sound, it should take you less than an hour to unpack all the components of the firmware. I had never unpacked a firmware before, but it only took me two evenings to get all the major pieces out. The offsets, sizes, compression, and filesystems are almost all documented right here in this forum, so there is no excuse not to take a look if you really want to test an idea.
I totally agree that the ratio of people waiting with high expectations to the people working on it is rather high. The Magic Lantern forums are just like that on a larger scale, but that doesn't change what they have or have not done. You need to keep in mind that this forum is a community of filmmakers, not hackers (or even "photographers"). The point of this thread in the first place was to show interest in modifying a camera, at which I'd say it has admirably succeeded!
Finally, nobody cares that you're a busy person. So you like your HoloLens and want to play with it. Cool story. We're all busy people too, so suck it up and either contribute or go back to lurking. Sorry for the tone, but that's because I can never stand people who drop into discussions and claim that they could do it all better if they didn't have so many more important things to do, yet don't contribute anything useful.
/rant

I kind of hope you're trolling, but I feel compelled to respond anyway.
tl;dr: Nobody has been making any implied promises, and your suggestion had already been tried and failed before you posted it.
First of all, nobody is claiming to be working on super-duper secret projects. Everyone has been very clear that they are doing this for fun in their spare time. From what I have read, nobody is releasing much since there isn't much interesting to release. For what it's worth, there have already been results, in particular from Otto and Vasile. Both of them made no promises yet delivered exactly what they said they expected to do. Vasile claimed to have found how to increase the bitrate, and provided a video as proof. Yea he could theoretically have faked it, but I see know reason to think that at this point. Otto stated his intentions very clearly and his results have already proven useful to people who want to take videos of events longer than 30 minutes (as well as anyone who wants to investigate their camera further).
You got radio silence on your suggestions because people were already working on that and ran into problems that you did not address at all. In case it's too much trouble for you to actually read what people have already written, the issue was that if the camera app is killed it freezes the camera. It's hard to replace an app if you cannot even remove it. If you think you know how to prevent that, I would love to hear it. If you want "traction" in this discussion, try actually being helpful.
Regarding the DRIMeV SoC itself, I mostly agree with your educated guess. It is almost certainly the same die, and the ARM cores are 100% identical. Unfortunately that's not saying much at all since most modern ARMv7 cores are identical as far as the software is concerned. It's the details of other blocks that would determine whether or not the important components of the camera application run or not. I can't tell just from skimming the kernel source code.
It takes under 5 minutes to find and download the firmware update from Samsung's site. If you really don't have 5 free minutes in your life, I don't understand why you are wasting time criticizing people who have actually accomplished things and posted them here. If you are 1/2 as smart as you make yourself sound, it should take you less than an hour to unpack all the components of the firmware. I had never unpacked a firmware before, but it only took me two evenings to get all the major pieces out. The offsets, sizes, compression, and filesystems are almost all documented right here in this forum, so there is no excuse not to take a look if you really want to test an idea.
I totally agree that the ratio of people waiting with high expectations to the people working on it is rather high. The Magic Lantern forums are just like that on a larger scale, but that doesn't change what they have or have not done. You need to keep in mind that this forum is a community of filmmakers, not hackers (or even "photographers"). The point of this thread in the first place was to show interest in modifying a camera, at which I'd say it has admirably succeeded!
Finally, nobody cares that you're a busy person. So you like your HoloLens and want to play with it. Cool story. We're all busy people too, so suck it up and either contribute or go back to lurking. Sorry for the tone, but that's because I can never stand people who drop into discussions and claim that they could do it all better if they didn't have so many more important things to do, yet don't contribute anything useful.
/rant

I kind of hope you're trolling, but I feel compelled to respond anyway.
tl;dr: Nobody has been making any implied promises, and your suggestion had already been tried and failed before you posted it.
First of all, nobody is claiming to be working on super-duper secret projects. Everyone has been very clear that they are doing this for fun in their spare time. From what I have read, nobody is releasing much since there isn't much interesting to release. For what it's worth, there have already been results, in particular from Otto and Vasile. Both of them made no promises yet delivered exactly what they said they expected to do. Vasile claimed to have found how to increase the bitrate, and provided a video as proof. Yea he could theoretically have faked it, but I see know reason to think that at this point. Otto stated his intentions very clearly and his results have already proven useful to people who want to take videos of events longer than 30 minutes (as well as anyone who wants to investigate their camera further).
You got radio silence on your suggestions because people were already working on that and ran into problems that you did not address at all. In case it's too much trouble for you to actually read what people have already written, the issue was that if the camera app is killed it freezes the camera. It's hard to replace an app if you cannot even remove it. If you think you know how to prevent that, I would love to hear it. If you want "traction" in this discussion, try actually being helpful.
Regarding the DRIMeV SoC itself, I mostly agree with your educated guess. It is almost certainly the same die, and the ARM cores are 100% identical. Unfortunately that's not saying much at all since most modern ARMv7 cores are identical as far as the software is concerned. It's the details of other blocks that would determine whether or not the important components of the camera application run or not. I can't tell just from skimming the kernel source code.
It takes under 5 minutes to find and download the firmware update from Samsung's site. If you really don't have 5 free minutes in your life, I don't understand why you are wasting time criticizing people who have actually accomplished things and posted them here. If you are 1/2 as smart as you make yourself sound, it should take you less than an hour to unpack all the components of the firmware. I had never unpacked a firmware before, but it only took me two evenings to get all the major pieces out. The offsets, sizes, compression, and filesystems are almost all documented right here in this forum, so there is no excuse not to take a look if you really want to test an idea.
I totally agree that the ratio of people waiting with high expectations to the people working on it is rather high. The Magic Lantern forums are just like that on a larger scale, but that doesn't change what they have or have not done. You need to keep in mind that this forum is a community of filmmakers, not hackers (or even "photographers"). The point of this thread in the first place was to show interest in modifying a camera, at which I'd say it has admirably succeeded!
Finally, nobody cares that you're a busy person. So you like your HoloLens and want to play with it. Cool story. We're all busy people too, so suck it up and either contribute or go back to lurking. Sorry for the tone, but that's because I can never stand people who drop into discussions and claim that they could do it all better if they didn't have so many more important things to do, yet don't contribute anything useful.
/rant

I kind of hope you're trolling, but I feel compelled to respond anyway.
tl;dr: Nobody has been making any implied promises, and your suggestion had already been tried and failed before you posted it.
First of all, nobody is claiming to be working on super-duper secret projects. Everyone has been very clear that they are doing this for fun in their spare time. From what I have read, nobody is releasing much since there isn't much interesting to release. For what it's worth, there have already been results, in particular from Otto and Vasile. Both of them made no promises yet delivered exactly what they said they expected to do. Vasile claimed to have found how to increase the bitrate, and provided a video as proof. Yea he could theoretically have faked it, but I see know reason to think that at this point. Otto stated his intentions very clearly and his results have already proven useful to people who want to take videos of events longer than 30 minutes (as well as anyone who wants to investigate their camera further).
You got radio silence on your suggestions because people were already working on that and ran into problems that you did not address at all. In case it's too much trouble for you to actually read what people have already written, the issue was that if the camera app is killed it freezes the camera. It's hard to replace an app if you cannot even remove it. If you think you know how to prevent that, I would love to hear it. If you want "traction" in this discussion, try actually being helpful.
Regarding the DRIMeV SoC itself, I mostly agree with your educated guess. It is almost certainly the same die, and the ARM cores are 100% identical. Unfortunately that's not saying much at all since most modern ARMv7 cores are identical as far as the software is concerned. It's the details of other blocks that would determine whether or not the important components of the camera application run or not. I can't tell just from skimming the kernel source code.
It takes under 5 minutes to find and download the firmware update from Samsung's site. If you really don't have 5 free minutes in your life, I don't understand why you are wasting time criticizing people who have actually accomplished things and posted them here. If you are 1/2 as smart as you make yourself sound, it should take you less than an hour to unpack all the components of the firmware. I had never unpacked a firmware before, but it only took me two evenings to get all the major pieces out. The offsets, sizes, compression, and filesystems are almost all documented right here in this forum, so there is no excuse not to take a look if you really want to test an idea.
I totally agree that the ratio of people waiting with high expectations to the people working on it is rather high. The Magic Lantern forums are just like that on a larger scale, but that doesn't change what they have or have not done. You need to keep in mind that this forum is a community of filmmakers, not hackers (or even "photographers"). The point of this thread in the first place was to show interest in modifying a camera, at which I'd say it has admirably succeeded!
Finally, nobody cares that you're a busy person. So you like your HoloLens and want to play with it. Cool story. We're all busy people too, so suck it up and either contribute or go back to lurking. Sorry for the tone, but that's because I can never stand people who drop into discussions and claim that they could do it all better if they didn't have so many more important things to do, yet don't contribute anything useful.
/rant

I've never seen a file manager report a file size in bits. It's always bytes. Computer hardware typically cannot even store or operate on a unit smaller than a byte independently. Megabits are almost exclusively used for data rates, not storage sizes.
Just to be sure I downloaded the files and checked them myself (on linux). Sure enough they are all at least 1 million bytes.
Therefore the correct calculation for the 2048x1152x15fps stream is 1.5*10^6 bytes/frame * 8 bits/byte * 15 frames/s = 180*10^6 bit/s, which is approximately 180Mbit/s.
Which is exactly what one would expect from typical JPEG compression ratios.

I've never seen a file manager report a file size in bits. It's always bytes. Computer hardware typically cannot even store or operate on a unit smaller than a byte independently. Megabits are almost exclusively used for data rates, not storage sizes.
Just to be sure I downloaded the files and checked them myself (on linux). Sure enough they are all at least 1 million bytes.
Therefore the correct calculation for the 2048x1152x15fps stream is 1.5*10^6 bytes/frame * 8 bits/byte * 15 frames/s = 180*10^6 bit/s, which is approximately 180Mbit/s.
Which is exactly what one would expect from typical JPEG compression ratios.

He's not a developer, he's a "Senior Marketing Manager."
If Samsung is like many other semiconductor and consumer electronics companies, I very well might.

Unfortunately that's not how it works. The framerate is inversely proportional to the number of lines, not the number of pixels. Getting much more than 120fps in 1080p would require an entirely new image sensor. The reason is that all modern cameras (apart from some exotic high-end stuff) use "column parallel" sensors.
The best affordable high-speed camera at the moment is probably the crowd-funded fps1000, if it's actually shipping yet.
Please quit saying that without any evidence. The processor does not limit the readout speed of each individual frame. The RAM in the NX1 is fast enough to store the data to be processed in way under 1/30 of a second (you can see the clock speeds for the RAM in the kernel source). It can do that in its sleep. Literally. According to the source code, the RAM is running at 400Mhz in sleep mode. There is no way it is de-bayering, scaling, and encoding the video line by line without putting it in a framebuffer first. Yes I know a Samsung representative said the sensor was really fast in an interview, but the official Samsung website says otherwise. Furthermore every third-party test indicates otherwise. The proportionality between rolling shutter and lines of resolution in all real world tests agrees with my estimates. The information in the firmware release notes is consistent with those limitations. Every other camera ever made works like that.
The only way the processor could determine the rolling shutter is if they forced the LVDS receivers on the main SoC to run at a fraction of the rate they could be run at. That would be spectacularly stupid, since there are much easier ways to cripple a camera. Even if they knew about the details of the camera's operation, I doubt Samsung executives would choose to limit the camera in such a dumb, arbitrary way.
Unless you actually have evidence, stop spreading misinformation. It's a waste of time to keep explaining this over and over.

Unfortunately that's not how it works. The framerate is inversely proportional to the number of lines, not the number of pixels. Getting much more than 120fps in 1080p would require an entirely new image sensor. The reason is that all modern cameras (apart from some exotic high-end stuff) use "column parallel" sensors.
The best affordable high-speed camera at the moment is probably the crowd-funded fps1000, if it's actually shipping yet.
Please quit saying that without any evidence. The processor does not limit the readout speed of each individual frame. The RAM in the NX1 is fast enough to store the data to be processed in way under 1/30 of a second (you can see the clock speeds for the RAM in the kernel source). It can do that in its sleep. Literally. According to the source code, the RAM is running at 400Mhz in sleep mode. There is no way it is de-bayering, scaling, and encoding the video line by line without putting it in a framebuffer first. Yes I know a Samsung representative said the sensor was really fast in an interview, but the official Samsung website says otherwise. Furthermore every third-party test indicates otherwise. The proportionality between rolling shutter and lines of resolution in all real world tests agrees with my estimates. The information in the firmware release notes is consistent with those limitations. Every other camera ever made works like that.
The only way the processor could determine the rolling shutter is if they forced the LVDS receivers on the main SoC to run at a fraction of the rate they could be run at. That would be spectacularly stupid, since there are much easier ways to cripple a camera. Even if they knew about the details of the camera's operation, I doubt Samsung executives would choose to limit the camera in such a dumb, arbitrary way.
Unless you actually have evidence, stop spreading misinformation. It's a waste of time to keep explaining this over and over.

He's not a developer, he's a "Senior Marketing Manager."
If Samsung is like many other semiconductor and consumer electronics companies, I very well might.

Here you go
http://***URL removed***/forums/thread/3979382#forum-post-57446956