Running shell scripts off the SD card with NX500 and no firmware hack. Don't get too excited yet.

I tried it. It still isn't working. It was doing the same thing the other day and all of sudden it started producing the output files.

I tried the telnetd way too, but I am hitting a wall there too :

C:\Windows\System32>telnet 192.168.1.44
Connecting To 192.168.1.44...Could not open connection to the host, on port 23:
Connect failed

I've made sure port 23 is open through firewall.
 
You cannot just connect to 192.168.1.44 - that is IP the camera received from my wireless router. You have to check on your own network where the camera is. You could use nmap or similar network scanner and scan wireless devices on your own network.

Also, I set up a github.com repo for all this in one place :

https://github.com/ottokiksmaler/nx500
 
Last edited:
Yeah I realised that soon after I posted. I have found the IP address of mine (192.168.0.5), but I still get the same message. I tried through cmd and a couple IP scanners which have a telnet option.

I downloaded the busybox folder you uploaded on EOSHD, renamed the folder to " telnetd" and placed it at the root of my SD card. After I turn on the camera, I wait a bit and connect to the router my laptop is connected. I then run cmd.exe as admin and type " telnet 192.168.0.5", but I am still getting the message I posted earlier. Anything else I am missing?

Also, the other method with the 3 files, why does it work so erratically (I've added sync a few times at the end of test.sh)?

--
https://www.flickr.com/photos/giannis_ch/
 
Last edited:
Thank you very much for creation the github link - the biggest contribution in this field until now!

It is incredible that 120fps 1080p works on NX500!

I just hope that there will be something like "DoubleBitrate-NX500-NX1.md" one day :-)
 
Last edited:
Here are my findings, the 1080 120p looks much better than the 720 120p. BUT the 2560x1440 looks like absolute garbage... It has lower bitrate than 1080 30p on normal quality and looks worse. Very bad macroblocking and low quality.

So until we find a way to change the bitrate settings the 2560x1440 is not very useful. but the 1080 120p is very useful.
Is 1440P a full pixel read out or cropped one?

Thank you for sharing the info.

ILHYOUNG.
 
Huge thanks otto k for the github all the tinkering.

Hopefully will see an unlimited recording workaround.

Not much of a Linux guy myself, can any of those scripts be called by camera button press? Form what I read doesn't look like we are at that stage yet or am I wrong?
 
According github and other posts here it is without crop - but bitrate is so low (15mbits I think) that it is hardly usable...
 
a real advancement would be to understand how resolution is passed, so to enable 2.5k on NX1 at highest possible bitrate. IMO 2.5k@80Mb would be better than 4K@80Mb, when resizing to FHD.
 
According github and other posts here it is without crop - but bitrate is so low (15mbits I think) that it is hardly usable...
Correct on both points. It does not crop, and it looks like poo.
 
a real advancement would be to understand how resolution is passed, so to enable 2.5k on NX1 at highest possible bitrate. IMO 2.5k@80Mb would be better than 4K@80Mb, when resizing to FHD.
Actually, this is one of the most interesting aspects of this tweaking. We use professionaly 2.7K files from GoPros all the time, while 4K is completely overkill for now. All our editing suites are optimized with 2.5K monitors, and 4K editing and post production is an expensive nightmare right now, and no customers ask for 4K anyway!
 
I ran some more tests last night and unfortunately this is definitely not recording real 1080 120P. It's 1080 30P that is then saved to a file on a 120P timeline.

That's the same reason 1440P doesn't look good, because it's a 1080P image being stretched to 1440P.
 
I ran some more tests last night and unfortunately this is definitely not recording real 1080 120P. It's 1080 30P that is then saved to a file on a 120P timeline.

That's the same reason 1440P doesn't look good, because it's a 1080P image being stretched to 1440P.
So when you slow it down on an editor it's not smooth?

I hadn't tried anything other than playing the raw file right out of the camera and looking at the details tab to see it showed 120p
 
a real advancement would be to understand how resolution is passed, so to enable 2.5k on NX1 at highest possible bitrate. IMO 2.5k@80Mb would be better than 4K@80Mb, when resizing to FHD.
The those settings predefined quality / bitrate, which makes me think this is only some internal programming leftovers for testing, which would explain the lack of the PAL options too.

If we were only making changes to the resolution the "quality" settings would be independent, so I guess that's not the right way to go on to achieve this.

Wouldn't he best case would be figuring out what variables/registers are modified when changing the resolution and quality, and modify those to change how the encoder is created?

/*
* drime5 specific encoder structure.
*
* @drm_encoder: encoder object.
* @manager: specific encoder has its own manager to control a hardware
* appropriately and we can access a hardware drawing on this manager.
* @dpms: store the encoder dpms value.
* @updated: indicate whether overlay data updating is needed or not.
*/
 
So it sounds like we have confirmed same memory and same processor between NX1 and NX500. I would imagine heat becomes an issue with trying to get non-cropped 4K video.

I would be really happy with non-cropped 1440p video at 30fps in a decent bitrate - if the camera can do 60fps at 1080p I'm guessing it wouldn't be overkill to do this. I don't understand why nothing exist between 1080p and 4k in the default firmware.

My only other wish at my skill level would be more compatibility with external mics since the em10 is rare and expensive now.

Beyond that I see discussion on features I know nothing about that are probably really nice too. This is exciting and counteracts and negative stuff Ive read about Samsung reducing their market.
 
Could you send the lines mentioning CMA from dmesg or ###_a9_dmesg.info file or, better yet, first 36 lines? For NX500 they are:

I'm trying to find a hardware difference between CPUs (I want to try porting or mixing firmwares).
First of all a big thumbs up to you for all the excellent work you're doing. The GitHub repository is particularly appreciated as it allows us to have all the essential information in one easily accessible place, without having to dig through all the posts on the forum.

I have both the NX1 and the NX500 so I'll be able to help test the changes between the two.

Here are some key differences between NX1 and NX500 (< is NX1, > is NX500):

7,8c7,8

< cma: CMA: reserved 256 MiB at 96000000

< cma: CMA: reserved 128 MiB at 8e000000

---

> cma: CMA: reserved 288 MiB at 94000000

> cma: CMA: reserved 72 MiB at 8f800000

25c25

< Memory: 115000k/115000k available, 409288k reserved, 0K highmem

---

> Memory: 142828k/142828k available, 381460k reserved, 0K highmem

56c56

< [arch/arm/mach-drime5/board-d5_nx1.c, fn:drime5_es_init, 3636] wm8962

---

> [arch/arm/mach-drime5/board-d5_nx500.c, fn:drime5_es_init, 1745] nau8822

58,59c58,59

< DRIME5: IDS : 26(ISP), 38(ARM) PROMISE : 87 RESULT : 6

< DRIME5 ASV : 6 Group

---

> DRIME5: IDS : 23(ISP), 35(ARM) PROMISE : 82 RESULT : 5

> DRIME5 ASV : 5 Group

93a110

> VDD_ISP: 770 <--> 1400 mV at 870 mV

96d112

< VDD_ISP: 770 <--> 1400 mV at 1030 mV

As you can see, even though both cameras seem to be using the same processor and amount of memory there are some subtle differences in between the two. There are many more differences but unfortunately this particular forum is not very code friendly, so posting them all here is a bit cumbersome.

Below you can find the full first 35 lines from dmesg on the NX1:

[ 0: 0.000000] I/KERNEL (K 0): Booting Linux on physical CPU 0

[ 0: 0.000000] I/KERNEL (K 0): Initializing cgroup subsys cpu

[ 0: 0.000000] I/KERNEL (K 0): Linux version 3.5.0 (jhny.park@SWDA7604) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1456 PREEMPT Fri Aug 7 17:12:47 KST 2015

[ 0: 0.000000] I/KERNEL (K 0): CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c53c7d

[ 0: 0.000000] I/KERNEL (K 0): CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[ 0: 0.000000] I/KERNEL (K 0): Machine: Samsung-DRIMe5-ES

[ 0: 0.000000] I/KERNEL (K 0): cma: CMA: reserved 256 MiB at 96000000

[ 0: 0.000000] I/KERNEL (K 0): cma: CMA: reserved 128 MiB at 8e000000

[ 0: 0.000000] I/KERNEL (K 0): Memory policy: ECC disabled, Data cache writeback

[ 0: 0.911665] I/KERNEL (K 0): On node 0 totalpages: 131072

[ 0: 0.921537] I/KERNEL (K 0): free_area_init_node: node 0, pgdat c0a47ac0, node_mem_map c0a7b000

[ 0: 0.921547] I/KERNEL (K 0): Normal zone: 1024 pages used for memmap

[ 0: 0.921554] I/KERNEL (K 0): Normal zone: 0 pages reserved

[ 0: 0.921561] I/KERNEL (K 0): Normal zone: 130048 pages, LIFO batch:31

[ 0: 0.960644] I/KERNEL (K 0): L310 cache controller enabled

[ 0: 0.960659] I/KERNEL (K 0): l2x0: 16 ways, CACHE_ID 0x4100fcc8, AUX_CTRL 0x40030001, Cache size: 262144 B

[ 0: 0.960756] I/KERNEL (K 0): pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768

[ 0: 0.960767] I/KERNEL (K 0): pcpu-alloc: [0] 0

[ 0: 0.960783] I/KERNEL (K 0): Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048

[ 0: 0.960792] I/KERNEL (K 0): Kernel command line: console=ttyAMA0,115200n8 mem=512M hibernate=nocompress root=/dev/mmcblk0p10 rw rootfstype=ext4 rootwait noresume user_debug=255

[ 0: 0.960944] I/KERNEL (K 0): PID hash table entries: 2048 (order: 1, 8192 bytes)

[ 0: 0.961402] I/KERNEL (K 0): Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)

[ 0: 0.962063] I/KERNEL (K 0): Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)

[ 0: 0.983616] I/KERNEL (K 0): Memory: 512MB = 512MB total

[ 0: 0.983624] I/KERNEL (K 0): Memory: 115000k/115000k available, 409288k reserved, 0K highmem

[ 0: 0.983653] I/KERNEL (K 0): Virtual kernel memory layout:

[ 0: 0.983653] I/KERNEL (K 0): vector : 0xffff0000 - 0xffff1000 ( 4 kB)

[ 0: 0.983653] I/KERNEL (K 0): fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)

[ 0: 0.983653] I/KERNEL (K 0): vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)

[ 0: 0.983653] I/KERNEL (K 0): lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)

[ 0: 0.983653] I/KERNEL (K 0): modules : 0xbf000000 - 0xc0000000 ( 16 MB)

[ 0: 0.983653] I/KERNEL (K 0): .text : 0xc0008000 - 0xc09e16a0 (10086 kB)

[ 0: 0.983653] I/KERNEL (K 0): .init : 0xc09e2000 - 0xc09ffbbc ( 119 kB)

[ 0: 0.983653] I/KERNEL (K 0): .data : 0xc0a00000 - 0xc0a49898 ( 295 kB)

[ 0: 0.983653] I/KERNEL (K 0): .bss : 0xc0a498bc - 0xc0a7a7d0 ( 196 kB)
 
That is correct. Take your NX500 and film a video playing on your TV. When you play it in VLC straight out of the camera at 0.25x speed, you'll be watching the video in realtime. That means that it's filming at 30P and simply stretching out the video by 4x during the file save process.
 
So it sounds like we have confirmed same memory and same processor between NX1 and NX500. I would imagine heat becomes an issue with trying to get non-cropped 4K video.
I don't think that can be a real issue.
Even if there is less efficiency in the thermal regulation, that *may* become a problem only after some period of working. So even if that were to be a problem, you should be able to record for some time before overheating becomes an issue.
My only other wish at my skill level would be more compatibility with external mics since the em10 is rare and expensive now.
From what I understood em10 is not even compatible, but more concerning was that when external mic is set ( st misc ext_mic ) there's an error event (maybe it's not implemented)
 
Off Topic: Is "Ottokiksmaler" a homage to the legendary works of Pahek?

Double respect if so ;)
 
So it sounds like we have confirmed same memory and same processor between NX1 and NX500. I would imagine heat becomes an issue with trying to get non-cropped 4K video.
I don't think that can be a real issue.
Yes, keep in mind that the original developers had to consider the long-term potential of customer support issues when they were enabling features. The hardware is likely capable of way more than what Samsung was prepared to guarantee and stand behind.
 
Last edited:

Keyboard shortcuts

Back
Top