Modding the Kodak Reels 8mm Film Digitizer (Firmware Hack)
- Thread starter Mac84
- Start date
I wanted to look at the display, or the exact type, to see the differences between the A, B and C models. I dropped the display, I tried to catch it and I brushed against a glass bottle which then fell directly onto the display. Now it is broken, you can only see very faintly that the backlight is still working. Well, the device still works, but it's difficult to use when flying blind :-(
Oh, that would be very little RAM. One approach could be to set the GOP to a smaller value, I think a sequence of I- and P-frames is always written directly to the SD card. This could possibly reduce the RAM load.
Unfortunately, I haven't gone any further because of the setback with the display, that was already a stupid event.
Last edited:
This is probably old news, but here's the datasheet for the Novatek chipset: https://dashcamtalk.com/cams/Novatek NT96655 Data Sheet.pdf
And there's some dashcam guys that worked with similar chipsets a decade ago. Maybe some of what they found would work with our machines?
dashcamtalk.com
xdaforums.com
And there's some dashcam guys that worked with similar chipsets a decade ago. Maybe some of what they found would work with our machines?
novatek
dashcamtalk.com
AZDome A305 - Wi-Fi Dash Camera - NT96658 | Sony IMX323 | 12MP | G-Sensor
Introduction This is the AZDome A305 Hardware This device is powered by a Novatek NT96658 Chipset with a Sony IMX323 Sensor. Just like most products from China, including smartphones, it is common to use interpolation to increase the...
xdaforums.com
I also found the NT96655, I hoped to find what the differences are to the 96658, as the 55 doesn't have integrated RAM. I think I'm over my confusion able the tiny RAM size. There seem to be plenty of unused memory.
Here is an crudely annotated memory dump during 1920x1440 capture (1920x1440 sensor data, processing and encoding):
More resolution raw data:
Here is an crudely annotated memory dump during 1920x1440 capture (1920x1440 sensor data, processing and encoding):
More resolution raw data:
Something doesn't quite add up, which where the video corruption could be coming from.
Here we see Luma data straddling 0x06000000. Yet on the console there is this info:
H264 is initializing something at 0x060A55C0, which in the middle not the top a the frame buffer. This address doesn't move for other resolutions.
Note: 0xA60A55C0 and 0x060A55C0/0x860A55C0, are all the same address. The 0xA address is likely a non-cache version of the address.
When I capture and process at 848x636 and encode at 1920x1440. The top of the video buffer lines up with 0xA60A55C0, and the resulting images are good (just lower stock resolution.)
Clearly a new memory map supporting the large images needs to be fixed. Any ideas for next steps?
--
UPDATE: I the position of the text for 0x06000000 is wrong in the video. The top of the luma frame is at 0x060A55C0. So this initialization of the encoder is correct., something else is still wrong.
Here we see Luma data straddling 0x06000000. Yet on the console there is this info:
H264 is initializing something at 0x060A55C0, which in the middle not the top a the frame buffer. This address doesn't move for other resolutions.
Note: 0xA60A55C0 and 0x060A55C0/0x860A55C0, are all the same address. The 0xA address is likely a non-cache version of the address.
When I capture and process at 848x636 and encode at 1920x1440. The top of the video buffer lines up with 0xA60A55C0, and the resulting images are good (just lower stock resolution.)
Clearly a new memory map supporting the large images needs to be fixed. Any ideas for next steps?
--
UPDATE: I the position of the text for 0x06000000 is wrong in the video. The top of the luma frame is at 0x060A55C0. So this initialization of the encoder is correct., something else is still wrong.
Last edited:
I found some info on the NT96658 on a Chinese site. To get the entire doc would entail setting up an account and a credit card. It being China, I was reluctant to go that far. But I was able to screen shot the first spec pages that may or may not help you guys. See attached DOCX file. It does have 1GB of ram.
Thank you. "Built-in 1Gb DDR3 SDRAM" , now triply confirmed. This feature sheet is good to see.
So I did a couple runs on my two units to see the various C version firmwares. The 0dan0 C firmware definitely has better clarity than the Mac84 version. For both cases I tried the full zoom out/left, Exposure -0.5, Sharpness -1.5, and Tint 0. My 0dan0 unit I had "adjusted" the focus of the camera, although in the end it was exactly in the factory spot when I was done. I didn't adjust the camera on my Mac84 unit.
The one thing I didn't like is going that far negative in sharpness is it left the image very smooth yet blurry feeling. I reran a 0dan0 scan with +0.5 sharpness, and though I got more noise I felt like I also got a little more detail, I.E. a little more texture to the grass, the grey pants had obvious wrinkles, etc.
The one thing I didn't like is going that far negative in sharpness is it left the image very smooth yet blurry feeling. I reran a 0dan0 scan with +0.5 sharpness, and though I got more noise I felt like I also got a little more detail, I.E. a little more texture to the grass, the grey pants had obvious wrinkles, etc.
I think it's not 1GB , above in this document there is 16KB data cache (upper case B) , almost used for bytes, below at built-in memory they used 1Gb (lower case b) almost used for bit. :-(
Today's progress. I did a series of captures, erasing the memory between captures so I could more easily see how the memory was being used (from the shell: mem fill 82000000 04000000 ff). Each capture use a different source resolution, all encoding to 1920x1440. The encoding resolution is not the problem, but the source resolution has a fixed buffer size. The incoming source 4:2:0 data is stored in two buffers, likely a double buffer, one for even frames, the other for odd numbered frames. The first frame is always at 0x250A3F0 and the second at 0x25E4BB0. As the input resolution increases (when you zoom out), more of the buffer is used. The gap between the buffers is only 894912 bytes. This sets the maximum source resolution at ~892x668, way short of the 1920x1440 we want. When source resolution is above the gap size, the buffers collide (areas in red), explaining the glitching seen. Also the second frame buffer bleeds into something potential used for compressed data (the non-YUV data glitches.)
This is the new target, increase the size of these two frame buffers. All help welcome as I don't know my next step.
This is the new target, increase the size of these two frame buffers. All help welcome as I don't know my next step.
Last edited:
"I think it's not 1GB , above in this document there is 16KB data cache (upper case B) , almost used for bytes, below at built-in memory they used 1Gb (lower case b) almost used for bit. :-("
Wow. Good catch Hawke (eye). So we have a gray area in our knowledge again? Is it possible for one of you coders to write/compare data to memory past the 1Gb boundary and see if it errors out then?
Wow. Good catch Hawke (eye). So we have a gray area in our knowledge again? Is it possible for one of you coders to write/compare data to memory past the 1Gb boundary and see if it errors out then?