RieGo

thanks a lot for the detailed explanation. i really enjoyed reading through it! I guess you have to rethink this. the camera doesn't actually encode 120 frames per second. it encodes 30 frames (my tests showed it's probably 25 frames) in one second of realtime. once it finished (or more probably also while) recording it tells the container that this, say 1000 frames, should be played back at 120f/s. which makes it basically really fast -> timelapse. camera didn't have to do any more work than in 30p. btw take a look at http://***URL removed***/forums/post/57866447 for framerate/resolution/slot tests and sample files

just in case anyone missed it and wants to help: vasile started a gofundme for a sacrificial hack camera. all details here: https://www.gofundme.com/22d7kj8

true. also many people are watching it on 1080p monitors, which obviously downsamples as well....

i completely forgot about this! so what do nx500 people think?

regarding the sharpness: i'm starting to believe -10 = no post sharpening, like someone else suggested. i did some tests with many details and sharpening -10. i couldn't find any interpolated edge sharpening, which is usually visible by ringing artifacts. my consumption: the oversharpening some are seeing is a result of a downsampler, probably bicubic ... is there a way to change this? i don't know.

so there is a little misconception: the higher the bitrate/quality the encoder has to output the more work he has to do. so it's usual (at least in my experience) for encoders to get slower while bitrate increases. you can try a simple x264 crf 18 vs x264 crf 30 to see what i'm talking about. also don't forget: a major quality decrease at 120p compared to 30p/60p comes from no full sensor readout, which also makes it harder to compress because of more noise.

i manually worked through all values by inputting them and looking at the camera icon. don't know if there's an easier way... btw: ignore the "seems like 9 sets it to fhd24" was a misconception 9 is just undefined like any other value >14

This is still true. the final file HAS 180MBit/s so they ARE used. This is no fill up data or anything like this.... well i can't proof that, but i'm pretty sure there is no such thing as filling data in mp4 containers... only television packets use filling data because they have to use a defined constant data rate. sorry, that was a lot of "filling data" but "filling data" is the only way i know to make bits disappear

alright, my bad. anyways "resolution show" doesn't give any output on terminal. maybe it's just in log or something... i'm just running the video tests. just looks like a bunch of small videos in different resolutions... btw: at "basic" and "full" test my battery turned from 50% to 0% in like 5 minutes until camera turned off... maybe that's part of the test or my battery is broken

just tried "st app nx record start" and "st app nx record stop". works just as expected, starts and stops video recording. but i have no clue how to use the resolution parameter... i tried but couldn't get to change anything. is this even what you are thinking about? i have no clue resolution [show,name] -> this arguments seem like only predefined resolutions can be used

MOV_SIZE on NX1: dc24p=0 uhd30=1 uhd24=2 uhd23.98=3 fhd120=4 fhd60=5 fhd30=6 fhd24=7 fhd23.98=8 hd60=10 hd30=11 vga60=12 vga=13 mjpeg=14 i think i give 9 a try lol -> seems like 9 sets it to fhd24 btw: someone did the same for NX500 at dpreview: http://***URL removed***/forums/thread/3985980

that's doable. i can upload my nx1 rootfs dump and you can do whatever you want with it. or maybe someone else. i haven't looked at it very much. http://www14.zippyshare.com/v/H7PRdH4S/file.html btw: an nx500 dump would be nice to see, so we could compare stuff...

it SHOULD not make any problems. it's disabled on mine since that hack came up. but please make sure to follow the manual closely. you don't need to disable recording limit for this.

averaging two frames should be completely equal to doubling the shutter time. i think we can agree on that if you're into avisynth: qtgmc contains a part where it can simulate motion blur, i.e. when you discard one field on interlaced source, making it half shutter angle. OR when you set your shutter speed too high, cause this is something that's not as easy. but that's a very exceptional case...

yeah, i didn't know that this is available on average cameras. this is new to me. 1/30 is no hardcoded limit, as it's 1/25 (i think) on 24p and pal 25p, so it's linked to video framerate

that's how video recording works. you cannot open the shutter longer than the duration of a frame. only very expensive cams can do this afaik. also you would get a lot of blur. i highly doubt this will be possible on this camera with a hack. well, if someone manages to make fps freely adjustable you could set it to 10fps and you'd get your 1/10 :-)

omg i never realised you get so much ugly sharpening, even though you did sharpness -10. seems like video postprocessing messes things really up. so let's assume we get mjpeg codec - wouldn't it go through the same video processing? i think so. we definitely need a way to go around this horrible sharpening... OR it really is a sideeffect of hevc... i'm not sure. well, ungraded looks way better (still too much) in terms of sharpness. did you do any post sharpening?

just follow this instructions: https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/DEV%20and%20CS%20modes.md But instead of disabling recording limit just use this setting: 2. SYSTEM PARAMETER (6) NO LENS RELEASE ENABLE [v] please be careful, the dev menu is dangerous!

i'm on windows. i see your point. new tech definitely needs some time to get widely adopted... let's just hope in a few years it will be as compatible as h264. in the meantime the only option is to convert the files before working with them, or hopefully someone can get some different encoding working on this firmware. only time will tell

I'm using an up-to-date Premiere Pro and nowadays it's no problem at all to work with hevc. the only thing premiere has difficulties with is reading the color range 0-255 from the NX1. if you got performance problems you probably just need hevc hardware decoding (intel skylake or nvidia 960 or 970 i think)

44.328 KB/s Samsung Pro SDXC 64GB UHS-I tested on NX1. btw: i found there's a lot of speed variation with this benchmark. i got results from 33.xxx to 44.xxx so i just used the fastest...

interesting disovery. any idea how this works? do you have to do anything other than just wait? i didn't know ois can be calibrated...

well, you can use the 2d/3d 45mm nx lens to capture 3d. so i guess you can watch it at least on your tv afterwards it also mentions dropbox and youtube and stuff, that's really weird.

that's interesting! i didn't take a look at the edj files yet. i was just about to decompile the binary. i see there is still a lot to explore...

seems like that com.samsung.di-camera-app is something like the complete gui of the camera. at least it contains all icons and images. so i'm currently taking a really close look at it as well too bad it's a compiled binary...