vasile
Members-
Posts
95 -
Joined
-
Last visited
Content Type
Profiles
Forums
Articles
Everything posted by vasile
-
Request: http://***URL removed***/forums/post/57640350 Thanks
-
I think someone said that on old firmware versions the photo NR settings would also apply to video. I tried to find the post but could not. Would a kind soul point me in the right direction, and could someone retest that firmware version to confirm? Maybe I can dig something out from that firmware to see what they changed for current firmware version.
-
Edit 2. Just thought: what if each frame is first NR-ed and only afterwards sent to the encoder? I do not think what we see in the sample is really high iso noise. I have been looking for two evenings in the NX500 code to try to see how the codec is initialized, looking in the drime kernel driver (see open source NX500 package) and various libraries. I do not yet understand how/when the codec initialization takes place. In any case if you look at the hevc codec interface source code (kernel/linux-3.5/drivers/media/video/drime5/hevc) you can see that there is definitely no NR switch passed on to the codec (which by the way is a FPGA). In these files you can see all configurable elements of the codec - unfortunately without explanations, but it is pretty clear to me that NR is not part of them. Maybe someone who is more of an expert can look into these files to see if I have missed anything. One interesting thing I noticed there is that apparently the codec admits type-iii gop :-) that seems equivalent to Canon's ALL-I gop - https://learn.usa.canon.com/resources/articles/2012/ipp_ipb_all_i_compare.htmlp The question is how does the di-camera-app set it. As for NR, given that there's no switch, unless someone finds it hidden amongst codec parameters (see above for where to look) I am afraid we are SOL. :-( Edit: these seem the most interesting files: d5_enc_host_api.c, d5_polarisCodec_host.h and d5_host_params.h - I attach them to this post. Edit 2: What if the image is denoised before being sent to the codec? d5_polarisCodec_host.h d5_enc_host_api.c d5_host_params.h
-
I know for sure Amazon charge what the market will bear :-) - which is remarkable for a camera more than 18 months old. I will keep an eye on it to see if they do sell it. As an interesting tidbit: they (amazon.fr) kept the price of the 30mm, for a long time, at 205 EUR, which was, incidentally, precisely what a French brick and mortar chain advertised it for (I think it was one of their last ones). A day after the non-amazon price disappeared, Amazon price suddenly went up to >300 EUR. I wonder why :-)
-
Not sure (read: I have no clue) what is going on in there. It is definitely not any parameter that I could see that is any different between the VGA slot settings and the 1080p settings except the resolution which I replaced in the VGA slot. Having said that, there are many many parameters set and reset in that general code area and I did not examine them in detail as this would be a very time consuming drudge work. I would have to step through the entire code between button push and release of controi to RTOS, manually record all parameter values that are sent out to the RTOS, and do it twice: for 1080p and then again for the VGA slot. I do not really want to do it :-(, especially since nothing is guaranteed: it might also turn out to be a matter of codec internal settings - i.e. if input matches preset => apply built-in preset [which might have NR=on] and for everything else, apply generic settings that might have NR=off. I don't know. Also, when I was working on the initial bit rate hack, I manually inserted 4k resolution (directly in the CPU registers) at the point where this is passed on to the RTOS, whilst set on 1080p, because I was curious if it would then uncrop it - bad news there, crop stays - but I did not look at all into noise levels.
-
I doubt the BOM is over 200$ for the body, let us say 300 with manufacturing. The rest is retailer markup and getting a return on the investment in IP. IP investment can be considered sunk cost at this stage. I guess what I am trying to say is incremental cost/camera for Samsung is very very low, once they have written off development costs - which they seem to have done after the restructuring of their imaging division. So there's nothing to prevent them to continue to make just enough of them so they can still claim it is not discontinued, and keep their options open in case the market recovers.
-
I am fairly sure they will bring more in, but in an irregular fashion. All elements seem to point to Samsung not officially discontinuing the system and only running short-ish batches of items, depending on received orders. At some point B&H had them as "discontinued" then they got new ones, now they are again out of stock (ok discontinued, although at this stage I won't believe it yet, since they were suddenly "undiscontinued" just a week ago I think).
-
http://www.amazon.com/Samsung-Wireless-Smart-Camera-16-50mm/dp/B00V5UDU60/ref=sr_1_2?ie=UTF8&qid=1461082163&sr=8-2&keywords=nx1 But please do not buy it in the hope that more capabilities would be unlocked by anyone. Nothing is guaranteed. See here why: http://***URL removed***/forums/post/57624059.
-
demanded != being useful/used.
-
AFAIK x265 != Samsung codec. Unless you have proof to the contrary...
-
That is one possibility. The options are there, how you use them depends on what your needs are.
-
Mod update for NX500 users here: http://***URL removed***/forums/post/57619677 NX1 users can stay on v2.0, no change - yet ;-) - for them. Enjoy...
-
Yes but not necessarily the best. I like more the nrmenable st cap live parameter from here: https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/ST%20Commands.md If I could find where it is set in di-camera-app I'd be in business.
-
eoshd is the "other" board mentioned here :-) http://***URL removed***/forums/post/57589144
-
Which means that the encoder block cannot deal with more than this bitrate at that size/fps. No other possible explanation so do not expect more from the camera as far as 1080p/120fps is concerned, unless you are willing to overclock.
-
As I wrote earlier, you should gradually decrease the mod bitrate for that video mode and check what this does to overall fps. At some point you will reach the point where the fps gets back to 120, at some max bitrate that will also depend on your card. Do not assume that max video bitrate for the camera is the same regardless of video size and fps combination because this is not true. The encoder workload is different between these even if the target bitrate is the same. Whilst we may start to play with the CPU speed/power profiles, and might be able to overclock it, I am not sure this is advisable - I think Samsung chose their power profiles based on engineering constraints and target environment factors (e.g. extreme usage like in the Nevada desert) with some margin too, but this does not mean that we should start playing with the fire. Unless you are willing to risk your camera's reliability and lifetime.
-
Overall top fps depends on multiple pipelines: sensor=>CPU, CPU=> memory, memory=>card, as well as on codec intrinsic speed. Hard to say which one impacts in this instance but my guess is that it's the codec (and by codec I mean the software and hardware together). You might think that the encoding CPU is less taxed with higher output rates but IMO that is not completely/always true.
-
I talk about reasonable possibilities that I see based on my current knowledge of NX innards. You talk about dreams/expectations. Two entirely different beasts.
-
No idea but I doubt it w/o replacing the codec. Chant might eventually be able to do something about it but don't hold your breath. At the moment I see a slight chance to get: more resolutions (i.e. 2.5K on NX1) the high rate 2.5K on NX500 (subject to dangerous manipulations on burner cam) maybe higher res and rate MJPEG out of NX1 (although TBH I do not think it would reach the quality of 150-160 Mbps hevc) with a lot of luck disable or reduce video NR (I might take a look at this at some point in the future but this will definitely involve weeks of work so not too keen to start). Basically Chant is looking into adding true new stuff. I have been looking more on the side of tweaking what's already in there - easier than Chant's ambitions but I already picked the low and medium hanging fruits.
-
Battery pull means no battery whatsoever, the camera should have no power source. Turning off is not enough. If you have two batteries you need to pull both. Will add this clarification to the next mod version.
-
Read the README.txt ;-) and also take a look at nx-bitrate-map.png
-
Useful (I hope) for both NX1 and NX500 users: http://***URL removed***/forums/post/57583300
-
resolution [show, name] means you can use resolution show or resolution name. Presumably resolution show would list available names to be used as "name" parameter for resolution "name"
-
Poll: burner NX500 for a chance [NB not a guarantee] to get "production" 2K5 high bitrate? http://***URL removed***/forums/post/57572799 rgds
-
read page 132 of this: http://downloadcenter.samsung.com/content/UM/201511/20151102105725627/NX1_English.pdf The mod currently replaces the instances of 80 Mbit/s from the table with whatever you pick. Other values are not currently affected. I plan to also enable changing some of the other values but you will need to be patient. Again, every setting combination that uses 80 Mbits/sec on the original firmware is replaced by my mod. The other values are not. My bet is you try to use a combination that results in 60 Mbit/s with the original firmware and that one stays on 60.