A binary file opened by Sublime HexViewer is like
ffff 0000 0001 0002 0003 0004 0005 0006 0007 0008 0009 000a
000b 000c 000d 000e 000f 0010 0011 0012 0013 0014 0015 0016
0017 0018 0019 .... eeee
Which has 12 columns. But I want to make all my binary files show like this when opened
ffff
0000 00010002
0003 00040005
0006 00070008
0009 000a000b
....
eeee
Is this possible?
Related
I am able to write NVS values by creating a pre-generate NVS data partition (as binary file) and write it in the esp32 partition. But I am unable to read these values despite there are indeed present in the NVS partition.
The commands I executed are:
1- nvs_partition_gen.py generate mfgdata.csv mfgdata.bin 0x5000
to get the pre-generate NVS data partition from
key,type,encoding,value
customNvs,namespace,,
batterySn,data,u32,65535
smartboxSn,data,u32,65534
test,data,u32,65533
2- parttool.py -p COM24 -b 115200 write_partition --partition-name=nvs --input=mfgdata.bin
to write the new NVS partition
I extracted the NVS partition and indeed, the value was there:
00000020: aaff ffff ffff ffff ffff ffff ffff ffff ................
00000030: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000040: 0001 01ff ba23 32a8 6375 7374 6f6d 4e76 .....#2.customNv
00000050: 7300 0000 0000 0000 01ff ffff ffff ffff s...............
00000060: 0104 01ff 24f9 ba27 6261 7474 6572 7953 ....$..'batteryS
00000070: 6e00 0000 0000 0000 ffff 0000 ffff ffff n...............
00000080: 0104 01ff 6a8e f27b 736d 6172 7462 6f78 ....j..{smartbox
00000090: 536e 0000 0000 0000 feff 0000 ffff ffff Sn..............
000000a0: 0104 01ff a69b 9df6 7465 7374 0000 0000 ........test....
000000b0: 0000 0000 0000 0000 fdff 0000 ffff ffff ................
000000c0: ffff ffff ffff ffff ffff ffff ffff ffff ...............
The problem is that I am not able to read these value. Before I wrote batterySn value thru Preferences API thru a bluetooth app.
I extracted NVS partition after setting batterySn thr the app and I get this:
00000040: 0001 01ff ba23 32a8 6375 7374 6f6d 4e76 .....#2.customNv
00000050: 7300 0000 0000 0000 01ff ffff ffff ffff s...............
00000060: 0104 01ff 24f9 ba27 6261 7474 6572 7953 ....$..'batteryS
00000070: 6e00 0000 0000 0000 ffff 0000 ffff ffff n...............
00000080: 0104 01ff 6a8e f27b 736d 6172 7462 6f78 ....j..{smartbox
00000090: 536e 0000 0000 0000 feff 0000 ffff ffff Sn..............
000000a0: 0104 01ff a69b 9df6 7465 7374 0000 0000 ........test....
.
.
.
00002380: 0204 01ff fd7a be81 7570 7469 6d65 0000 .....z..uptime..
00002390: 0000 0000 0000 0000 3c00 0000 ffff ffff ........<.......
000023a0: 0204 01ff 4bb2 b35d 6261 7474 6572 7953 ....K..]batteryS
000023b0: 6e00 0000 0000 0000 0100 0000 ffff ffff n...............
000023c0: 0204 01ff eab6 692c 7570 7469 6d65 0000 ......i,uptime..
000023d0: 0000 0000 0000 0000 7800 0000 ffff ffff ........x.......
My customNvs value are still there and there is batterySn value but in a different place. Only the second batterySn value can be read.
I tried to add a new argument to the write command like so:
parttool.py -p COM24 -b 115200 --partition-table-offset 0x9000 write_partition --partition-name=nvs --input=mfgdata.bin
Because my customNVS partition have an offset of 0x9000 but by doing that I get an error:
File "C:\ESP-IDF\components\partition_table\parttool.py", line 368, in <module>
main()
File "C:\ESP-IDF\components\partition_table\parttool.py", line 337, in main
target = ParttoolTarget(**target_args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\ESP-IDF\components\partition_table\parttool.py", line 119, in __init__
partition_table = gen.PartitionTable.from_binary(b)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\ESP-IDF\components\partition_table\gen_esp32part.py", line 231, in from_binary
result.append(PartitionDefinition.from_binary(data))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\ESP-IDF\components\partition_table\gen_esp32part.py", line 381, in from_binary
res.name = res.name.decode()
^^^^^^^^^^^^^^^^^
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte
Please tell me if my explanation is not clear enough or my process to write values in NVS partition is wrong.
My custom partition:
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000
otadata, data, ota, 0xE000, 0x2000
app0, app, ota_0, 0x10000, 0x2A0000
app1, app, ota_1, 0x2B0000, 0x2A0000
ffat, data, fat, 0x550000, 0x2B0000
I have an image file, which is 1048592 bytes length.
16 bytes header and 1048576 bytes data.
The begining bytes of its hex looks like below,
does anyone know how to decode it?
504b 4d20 3130 0000 0400 0800 0400 0800
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0203 0310 37ff ff00 485f 76d2 0d99 0331
7878 8f3e 110e 1186 2a2a 3bc9 7391 f733
1d1d 1de2 fff7 0008 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
0000 0002 ffff 0000 1213 14d0 337f 7f80
4444 4685 1d91 333f 2636 37cd 3b9d 7fbb
0303 0315 f777 cccc 0000 0002 ffff 0000
0000 0002 ffff 0000 0000 0002 ffff 0000
....
The header states it is a PKM image format.
The format is:
4 byte magic number(504b 4d20): "PKM "
2 byte version "10"
2 byte data type: 0 (ETC1_RGB_NO_MIPMAPS)
16 bit big endian extended width
16 bit big endian extended height
16 bit big endian original width
16 bit big endian original height data, 64bit big endian words.
From Game Developers SE Question
PKM format for ETC1 texture (All OGLES 2.0 devices compatibles)
PKM is useful for packaging ETC1-compressed images, but like with PNG, it doesn't support actual texture features.
It seems like you met this image format:
https://community.arm.com/thread/3968
It has PKM 10 in the beginning
You can convert the "PKM 10" format .pkm files to .png format using the following program:
https://forum.ragezone.com/f857/pkm-encrypt-decrypt-convert-to-1179253/
I just need some clarification on how to properly convert rgb pixel values in the range [0,1] to be in the right range for a HDR format like openEXR.
So I know for instance that when working with low dynamic range formats like PNG or JPG that only have 8 bits per channel, you simply have to multiply each rgb value by 2^8-1 = 255 and clamp so that all your values are in the range [0, 255].
OpenEXR and other HDR formats use a half precision format with 16 bits per channel. So do I just do the same thing as before and multiply each channel by 2^16-1 = 65535 so that my new range becomes [0, 65535]?
EDIT
So I tried doing what I wrote above but when I try to display the openEXR file in photoshop it is completely white. It seems like any value greater than around 10 or so is too bright for photoshop to display properly which I find very odd. So this doesn't seem like the correct way to do it unless there is something wrong with photoshops display.
We are dealing with three related but different issues at the same time.
The first issue is that of range: are channels stored as values in the range [0, 1] or [0, 255] or [0, 65535]. Scaling (multiplying and possibly clamping) is what you do to convert from one range to another.
The second issue is that of raw sample size: how many bits do you use to store the value. This doesn't necessarily have to be the binary logarithm of the size of the range. For example, if your range is [0, 255], you could store the values in 8 bits where the least significant bits represents increments of 1, or in 6 bits where the least significant bit represents increments of 4, or in 10 bits where the least significant bit represents increments of 0.25. In fact, as we will see in the next issue, the increments do not have to be fixed.
The third and final issue is that of encoding: fixed point or floating point. When we say that we store values of [0, 255] in 8 bits or values of [0, 65535] in 16 bits, we usually mean integer encoding (a special case of fixed point where the least significant bit represents fixed increments of 1). When values are stored in the range [0, 1] however, regardless of the raw sample size, usually this implies floating point storage (where most bits are used to store the significand, while a few bits are reserved to store the size of the increment associated with the least significant bit). When we speak of "half precision", "single precision", "double precision", "extended precision" and so forth we also invariably mean floating point encoding.
So here is the catch: OpenEXR uses floating point encoding, in a format that is not built in to most programming languages. Most modern languages only have 64-bit floats, and if they offer anything else it's usually 32-bit floats (respectively double and float in the C family), but 16-bit floats are almost never available out of the box.
Half precision can represent values in the range [-65505, 65504], with 11 bits (slightly better than 3 decimal digits) of precision, while also being able to represent values as small as 2^-14. However, given that OpenEXR is a HDR format, you are probably not really expected to use the entire range because the number encoding is chosen to accomodate for (extreme) over- or underexposure. That is, unless your camera actually produces such an enormous dynamic range of values.
So you might not actually need to scale your channel values. However, given that you already start with values in [0, 1], you probably have floating point numbers stored in single or double precision and you'll have to transcode them to half precision. Depending on the programming language, the libraries and even the hardware platform that you use, there might be an off-the-shelf solution or you might need to do some bit-fiddling of your own. As a starting point I can only offer you this DuckDuckGo search.
I'm too tired to think straight, but this may help you work it all out. I used ImageMagick to create three OpenEXR images, one white, one black and one red, all 1 pixel x 1 pixel.
convert -size 1x1! xc:white white.exr
convert -size 1x1! xc:black black.exr
convert -size 1x1! xc:red red.exr
Then I hexdumped them all:
xxd white.exr > white.txt
xxd black.exr > black.txt
xxd red.exr > red.txt
Here are the files:
White.txt
0000000: 762f 3101 0200 0000 6368 616e 6e65 6c73 v/1.....channels
0000010: 0063 686c 6973 7400 4900 0000 4100 0100 .chlist.I...A...
0000020: 0000 0000 0000 0100 0000 0100 0000 4200 ..............B.
0000030: 0100 0000 0000 0000 0100 0000 0100 0000 ................
0000040: 4700 0100 0000 0000 0000 0100 0000 0100 G...............
0000050: 0000 5200 0100 0000 0000 0000 0100 0000 ..R.............
0000060: 0100 0000 0063 6f6d 7072 6573 7369 6f6e .....compression
0000070: 0063 6f6d 7072 6573 7369 6f6e 0001 0000 .compression....
0000080: 0000 6461 7461 5769 6e64 6f77 0062 6f78 ..dataWindow.box
0000090: 3269 0010 0000 0000 0000 0000 0000 0000 2i..............
00000a0: 0000 0000 0000 0064 6973 706c 6179 5769 .......displayWi
00000b0: 6e64 6f77 0062 6f78 3269 0010 0000 0000 ndow.box2i......
00000c0: 0000 0000 0000 0000 0000 0000 0000 006c ...............l
00000d0: 696e 654f 7264 6572 006c 696e 654f 7264 ineOrder.lineOrd
00000e0: 6572 0001 0000 0000 7069 7865 6c41 7370 er......pixelAsp
00000f0: 6563 7452 6174 696f 0066 6c6f 6174 0004 ectRatio.float..
0000100: 0000 0000 0080 3f73 6372 6565 6e57 696e ......?screenWin
0000110: 646f 7743 656e 7465 7200 7632 6600 0800 dowCenter.v2f...
0000120: 0000 0000 0000 0000 0000 7363 7265 656e ..........screen
0000130: 5769 6e64 6f77 5769 6474 6800 666c 6f61 WindowWidth.floa
0000140: 7400 0400 0000 0000 803f 0053 0100 0000 t........?.S....
0000150: 0000 0000 0000 0008 0000 0000 3c00 3c00 ............<.<.
0000160: 3c00 3c <.<
Black.txt
0000000: 762f 3101 0200 0000 6368 616e 6e65 6c73 v/1.....channels
0000010: 0063 686c 6973 7400 4900 0000 4100 0100 .chlist.I...A...
0000020: 0000 0000 0000 0100 0000 0100 0000 4200 ..............B.
0000030: 0100 0000 0000 0000 0100 0000 0100 0000 ................
0000040: 4700 0100 0000 0000 0000 0100 0000 0100 G...............
0000050: 0000 5200 0100 0000 0000 0000 0100 0000 ..R.............
0000060: 0100 0000 0063 6f6d 7072 6573 7369 6f6e .....compression
0000070: 0063 6f6d 7072 6573 7369 6f6e 0001 0000 .compression....
0000080: 0000 6461 7461 5769 6e64 6f77 0062 6f78 ..dataWindow.box
0000090: 3269 0010 0000 0000 0000 0000 0000 0000 2i..............
00000a0: 0000 0000 0000 0064 6973 706c 6179 5769 .......displayWi
00000b0: 6e64 6f77 0062 6f78 3269 0010 0000 0000 ndow.box2i......
00000c0: 0000 0000 0000 0000 0000 0000 0000 006c ...............l
00000d0: 696e 654f 7264 6572 006c 696e 654f 7264 ineOrder.lineOrd
00000e0: 6572 0001 0000 0000 7069 7865 6c41 7370 er......pixelAsp
00000f0: 6563 7452 6174 696f 0066 6c6f 6174 0004 ectRatio.float..
0000100: 0000 0000 0080 3f73 6372 6565 6e57 696e ......?screenWin
0000110: 646f 7743 656e 7465 7200 7632 6600 0800 dowCenter.v2f...
0000120: 0000 0000 0000 0000 0000 7363 7265 656e ..........screen
0000130: 5769 6e64 6f77 5769 6474 6800 666c 6f61 WindowWidth.floa
0000140: 7400 0400 0000 0000 803f 0053 0100 0000 t........?.S....
0000150: 0000 0000 0000 0008 0000 0000 3c00 0000 ............<...
0000160: 0000 00 ...
Red.txt
0000000: 762f 3101 0200 0000 6368 616e 6e65 6c73 v/1.....channels
0000010: 0063 686c 6973 7400 4900 0000 4100 0100 .chlist.I...A...
0000020: 0000 0000 0000 0100 0000 0100 0000 4200 ..............B.
0000030: 0100 0000 0000 0000 0100 0000 0100 0000 ................
0000040: 4700 0100 0000 0000 0000 0100 0000 0100 G...............
0000050: 0000 5200 0100 0000 0000 0000 0100 0000 ..R.............
0000060: 0100 0000 0063 6f6d 7072 6573 7369 6f6e .....compression
0000070: 0063 6f6d 7072 6573 7369 6f6e 0001 0000 .compression....
0000080: 0000 6461 7461 5769 6e64 6f77 0062 6f78 ..dataWindow.box
0000090: 3269 0010 0000 0000 0000 0000 0000 0000 2i..............
00000a0: 0000 0000 0000 0064 6973 706c 6179 5769 .......displayWi
00000b0: 6e64 6f77 0062 6f78 3269 0010 0000 0000 ndow.box2i......
00000c0: 0000 0000 0000 0000 0000 0000 0000 006c ...............l
00000d0: 696e 654f 7264 6572 006c 696e 654f 7264 ineOrder.lineOrd
00000e0: 6572 0001 0000 0000 7069 7865 6c41 7370 er......pixelAsp
00000f0: 6563 7452 6174 696f 0066 6c6f 6174 0004 ectRatio.float..
0000100: 0000 0000 0080 3f73 6372 6565 6e57 696e ......?screenWin
0000110: 646f 7743 656e 7465 7200 7632 6600 0800 dowCenter.v2f...
0000120: 0000 0000 0000 0000 0000 7363 7265 656e ..........screen
0000130: 5769 6e64 6f77 5769 6474 6800 666c 6f61 WindowWidth.floa
0000140: 7400 0400 0000 0000 803f 0053 0100 0000 t........?.S....
0000150: 0000 0000 0000 0008 0000 0000 3c00 0000 ............<...
0000160: 0000 3c ..<
diff white.txt black.txt
22,23c22,23
< 0000150: 0000 0000 0000 0008 0000 0000 3c00 3c00 ............<.<.
< 0000160: 3c00 3c <.<
---
> 0000150: 0000 0000 0000 0008 0000 0000 3c00 0000 ............<...
> 0000160: 0000 00
The short answer is that this will probably not give you a useful result.
The moderately-long answer is that this approach makes a number of assumptions that are not at all "safe" with regard to image processing.
The primary assumption is that a Low Dynamic Range value of 255 represents an HDR value of 65535. The primary problem that HDR intends to solve is that real-world signals have to be compressed to a limited scope. Imagine taking a digital photograph of the sun directly: the input value for that light intensity is much greater than any imaging software supports, so it has to be compressed somehow. With LDR, the center of the sun's disk and much of the bloom around it will all be clamped to 255. With HDR, you're still clamping, but only to 65535. If you have a real-world signal which is giving values like 200, 255, 300 and 100,000, and then that gets clamped to 255, it should make sense that you cannot simply scale 255 to 65535 and get a reasonable result. That 255 might have been clamped from 256, or from 300, or from 100000; there's no way to know. (This is a radical oversimplification of imaging, but it should be sufficient for understanding this limitation in particular).
A secondary assumption is that what you see on your monitor has anything to do with the values in your image. The 0 - 65535 range of values in the image must be represented on your display, which is almost certainly limited to the sRGB spectrum (255). Mostly likely, if you've simply scaled 0-255 to 0-65535, then 99% of your range is above 255. So regardless of how much information is in your image, it's easy for it all to get clipped to "white."
Furthermore, depending on how Photoshop (or the GPU driver or the OS or the display panel) is translating your HDR 65535 into sRGB, it's just as likely that it's AGAIN being clamped to 255, or perhaps scaled "dumbly," or perhaps scaled "smartly," or any combination thereof. If Photoshop shows your image as solid white, you'll have to confirm a number of steps in the process to determine "who" in particular is transforming your color values, and how. Photoshop might be clamping before it sends to the OS. The OS might be clamping before it sends to the GPU. The GPU might be clamping when it sends to the display. The display might be clamping when it turns on the pixel. ...or any combination of clamping, scaling, and transforming at any of those steps (I know, not all of those combinations are actually possible, but the point is that there is a lot going on between the file and your eyeball).
Transforming LDR values to an HDR color space (and vice versa) is a non-trivial pursuit that represents a discipline unto itself. Depending on your application, you may need to do a great deal more research before you come to a good solution.
Why is awk not working for the following command instead of sed:
su -c "stdbuf -i0 -o0 -e0 od --width=144 -x /dev/input/event3 | sed 's%^\([a-z0-9]\+ \)\{11\}%%;s%\(....\).*%\1%'"
This prints at every keypress the USB HID ID number of the key that was pressed.
Example output (0028 is for Return and 00e4 for Right-Ctrl):
0028
0028
0028
0028
0028
00e4
00e4
00e4
This are two lines of output without sed/cut/awk filtering when pressing Return two times. The USB HID ID number is in column 12:
0000000 2d6f 511e 0000 0000 051b 0007 0000 0000 0004 0004 0028 0007 2d6f 511e 0000 0000 051d 0007 0000 0000 0001 001c 0000 0000 2d6f 511e 0000 0000 051e 0007 0000 0000 0000 0000 0000 0000 2d73 511e 0000 0000 a150 0007 0000 0000 0004 0004 0028 0007 2d73 511e 0000 0000 a153 0007 0000 0000 0001 001c 0001 0000 2d73 511e 0000 0000 a154 0007 0000 0000 0000 0000 0000 0000
0000220 2d73 511e 0000 0000 9b5a 0008 0000 0000 0004 0004 0028 0007 2d73 511e 0000 0000 9b5d 0008 0000 0000 0001 001c 0000 0000 2d73 511e 0000 0000 9b5e 0008 0000 0000 0000 0000 0000 0000 2d74 511e 0000 0000 4f90 0005 0000 0000 0004 0004 0028 0007 2d74 511e 0000 0000 4f93 0005 0000 0000 0001 001c 0001 0000 2d74 511e 0000 0000 4f94 0005 0000 0000 0000 0000 0000 0000
I tried it with
su -c "stdbuf -i0 -o0 -e0 od --width=144 -x /dev/input/event3 | cut -d' ' -f12"
and it also works. But it only shows the keys pressed after the next two keypresses. stdbuf did not help here, although it should adjusts standard input/output/error stream buffering to 0.
My mawk command looked like this:
su -c "stdbuf -i0 -o0 -e0 od --width=$((48*3)) -x /dev/input/event3 | mawk '{ print $12 }'"
but it only showed me some twos and then some newlines and again twos. It seems very laggy/slow. When I press a key, nothing happens. After pressing different keys multiple times, I always get a bunch of twos and newlines. No matter which keys I pressed! Example:
2
2
2
2
2
2
2
2
2
2
2
2
How can I fix this? Why is this occurring?
Update
When I use gawk instead of mawk it does not lag any more (unbuffered). But I still don’t see the correct values which should be 0028 or 00e4 and so on for Return and Right-Ctrl as example keys.
With all the comments I came to the solution.
#Olivier Dulac brought me to the idea that there are different awk implementations, which solved the problem of the laggyness (using gawk instead of mawk). I don’t even need the stdbuf.
#Ed Morton’s idea brought me to a problem, because he used quotes " in his example. I already had quotes in my statement around the whole thing, because it was executed using su. So I had to escape them.
My whole statement looks like this (notice the escaped dollar sign in front of the 12):
su -c "od --width=144 -x /dev/input/event3 | awk '{ print \$12 }'"
and now it works as expected.
Camtasia Studio is a software package for recording screen captures. One thing it does, it records the mouse movement coordinates separately from the video of your screen. It does this so you can modify the appearance of the cursor after you are done recording.
Once you have recorded your screen, it has an option for exporting the raw components of your capture. One of the files contains the cursor coordinates which look like this...
4556 5453 0300 0000 0c00 0000 0c00 0000
ca00 0000 0c00 0000 0100 0000 0000 0000
8002 0000 e001 0000 1900 0000 cb00 0000
1900 0000 0100 0000 0000 0000 000c 0259
0000 0059 0014 0000 00e0 e8ab 096a 032d
08b8 0100 00c8 0000 0008 0000 0037 0000
00b0 feff ffef 0328 02d2 0100 00f0 0328
02d2 0100 00f1 0329 02e0 0100 00f2 032a
02e0 0100 00f5 032b 02ed 0100 00f8 032d
02ed 0100 00fb 032f 02fa 0100 0001 0432
02fa 0100 0007 0435 0208 0200 000e 043a
0208 0200 0018 043f 0215 0200 0023 0445
0215 0200 002e 044a 0215 0200 0039 0450
0215 0200 0046 0455 0215 0200 004f 0458
0215 0200 0056 045a 022c 0200 005d 045e
022c 0200 0063 0462 0242 0200 0068 0465
0242 0200 006f 046b 0258 0200 0072 046f
0258 0200 0079 0476 0280 0200 0082 047d
0280 0200 0089 0484 028c 0200 0091 048a
028c 0200 0098 0494 029a 0200 009e 049c
029a 0200 00a3 04a0 029a 0200 00a7 04a3
029a 0200 00aa 04a6 02aa 0200 00af 04ab
02bc 0200 00b2 04ae 02bc 0200 00b4 04b3
02bc 0200 00b8 04b7 02cc 0200 00be 04bd
02cc 0200 00c1 04bf 02dd 0200 00c3 04c1
02dd 0200 00c6 04c4 02f8 0200 00c9 04c6
02f8 0200 00cb 04c8 0205 0300 00cc 04c9
0213 0300 00cd 04c9 0213 0300 00cd 04ca
0220 0300 00ce 04cb 0221 0300 00ce 04cc
0221 0300 00ce 04cd 0236 0300 00ce 04ce
0236 0300 00cd 04cf 024d 0300 00cc 04d0
024d 0300 00cc 04d1 0262 0300 00cb 04d2
0262 0300 00cb 04d3 0279 0300 00ca 04d3
02a5 0300 00c9 04d3 0218 0000 0002 0000
000c 0000 0002 0000 0000 0000 0081 0404
0487 06a5 04a5 0300 00f8 0304 0487 06ba
040a 0000 0003 0000 000a 0000 0001 0000
0000 0000 0000 0008 0009 000c 0000 0001
0000 000c 0000 0001 0000 0000 0000 00ff
033b 027f 061b 040c 0000 0005 0000 000c
0000 0001 0000 0000 0000 0000 0000 00ff
ffff ff0c 0000 0004 0000 000c 0000 0001
0000 0000 0000 0001 0000 0000 0000 001c
0000 002d 0100 001c 0000 0001 0000 0090
0300 0000 0100 0079 0000 0044 0000 0000
0000 0000 0000 0000 0000 00
This is from a 1 second recording. The screen capture size was 640x480. I was moving the mouse from the top left corner to the bottom right corner.
So here is my question. Is there a way to translate this information to time and X, Y coordinates of the video? I guess I just don't understand the notation but I want to use this information for my own project. Can anyone make sense of this data?