How can i insert a BLOB in mysql trough query - mysql

Does anyone know how i can enter an integer or hexadecimal value into a BLOB in mysql?
The endresult that i need is that the binary data of my blob contains:
Offset 1 2 3 4 5 6 7 8 9 A B C D E F
___________________________________________________________
0x00000000 15 AA 02 00 00 00 00 00 00 00 00 00 00 00 00
The current blob holds the value : 174613
So how would i write an insert/update query to put that value into this BLOBb?

Found a solution:
insert into tablename(columnname) values(x'15AA02000000000000000000000000')
columnname has to be of type BLOB.

Related

problem to decode H.264 video over rtp (unknown bytes between nal units)

I am trying to solve the problem of decoding H.264 over RTSP receiving from a HIK IP camera.
Payload Structure : STAP-A
SPS, PPS and SEI are transmitted at once like the below.
18 00 17 67 42 00 1E 96 35 41 40 7B 4D C1 40 41 00 10 50 00 00 70 80 00 15 F9 00 40 00 04 68 CE 31 B2 00 20 00 05 06 E5 01 4E 80
Unknown bytes are attached after SPS and PPS nal.
SPS is followed by (00 40) and PPS is followed by (00 20).
I want to know what it is and how to decode it.
I expected that 2 bytes containing the PPS nal length would be delivered right after the SPS nal length, but decoding is failing because there is unknown data.

What is the excess-65 exponent format?

According to the IBM Informix docs:
DECIMAL(p, s) values are stored internally with the first byte representing a sign bit and a 7-bit exponent in excess-65 format.
How does the "excess-65" format work?
References
DECIMAL(p,s) Data Types
DECIMAL Storage
The notation is specific to Informix and its DECIMAL and MONEY types — AFAIK, no other product uses it. Informix also uses it within its DATETIME and INTERVAL types, but that's an implementation detail for the most part.
I've always know the on-disk form as 'excess-64' rather than 'excess-65'; I'm not sure which is correct, but I think 64 has a solid basis.
The 'excess-6n' form is used for disk storage. It has the benefit that two decimal values in the disk format can be compared using memcmp() to get a correct comparison (though NULL values have to be handled separately — NULL values always cause pain and grief).
The decimal.h header from ESQL/C (and C-ISAM) contains the information:
/*
* Packed Format (format in records in files)
*
* First byte =
* top 1 bit = sign 0=neg, 1=pos
* low 7 bits = Exponent in excess 64 format
* Rest of bytes = base 100 digits in 100 complement format
* Notes -- This format sorts numerically with just a
* simple byte by byte unsigned comparison.
* Zero is represented as 80,00,00,... (hex).
* Negative numbers have the exponent complemented
* and the base 100 digits in 100's complement
*/
Note the mention of 64 rather than 65. Also note that 'decimal' is in some respects a misnomer; the data is represented using a 'centesimal' (base-100) notation.
Here are some sample values, decimal representation and then bytes for the on-disk format. Note that to some extent, the number of bytes is arbitrary. If using something like DECIMAL(16,4), there will be 1 byte sign and exponent and 8 bytes of data (and the range of exponents will be limited). If you use DECIMAL(16) — for floating point — then the range of exponents is much less limited.
Decimal value Byte representation (hex)
0 80 00 00 00 00
1 C1 01
-1 3E 63
9.9 C1 09 5A 00
-9.9 3E 5A 0A 00
99.99 C1 63 63 00 00 00
-99.99 3E 00 01 00 00 00
999.999 C2 09 63 63 5A
-999.999 3D 5A 00 00 0A
0.1 C0 0A 00 00
-0.1 3F 5A 00 00
0.00012345 BF 01 17 2D 00
-0.00012345 40 62 4C 37 00
1.2345678901234e-09 BC 0C 22 38 4E 5A 0C 22
-1.2345678901234e-09 43 57 41 2B 15 09 57 42
1.2345678901234e+09 C5 0C 22 38 4E 5A 0C 22
-1.2345678901234e+09 3A 57 41 2B 15 09 57 42
And so on.

How to communicate with a specific ECU using its physical address

Each time I send a query to the OBD2 I get two responses.
For instance, if I send 0105, I get
41 05 5C
7F 01 12
If I turn on header with AT H1 and then send 0105, I get
83 F1 11 41 05 5C
83 F1 18 7F 01 12
I only need the first response, the one from 83 F1 11
please, how do I specify that I want to communicate with only that ECU?
From "ELM Electronics - Circuits for the Hobbyist"
I know it should be done using AT SH but there are three options
available and I do not know which one to use:
AT SH xyz or AT SH xxyyzz or AT SH wwxxyyzz.
Btw my car is a Hyundai Tucson 2006, and runs protocol 5 that is
ISO 14230-4 KWP (fast init, 10.4 kbaud)
There are multiple ways. The most complicated one is setting the header address directly via ATSH. Way easier is appending the number of expected responses to the pid, i.e. 01001 will send 0100 and discards all but one response. The fastest ECU will win, which is not always what you want.
So another way is to filter by header, i.e.:
>0100
18 DA F1 10 06 41 00 B8 7B 30 10 00
18 DA F1 17 06 41 00 80 00 80 03 00
>AT CRA 18DAF117
OK
>0100
18 DA F1 17 06 41 00 80 00 80 03 00

How to understand header of H264

My NAL unit looks like this:
00 00 00 01 67 42 00 1F E6 20 0A 00 B6 60 22 00 00 03 00 02 00 00 03 00 79 C0 00 00 10 FD D0 00 00 40 16 43 F4 A4 18 00 00 03 02 1D 97 00 00 1A B3 F1 FA 52 05 00 00 00 01 68
How can I understand what is the data in RBSP? Like payload size and what parts of the data signifies it.
In the H264 format the byte stream is organised into many NAL unit. In order to understand where a NAL unit starts a three-byte or four-byte start code, 0x000001 or 0x00000001, is placed at the beginning of each NAL unit.
There is the possibility that this sequence is present also in the raw data, in this case an emulation prevention byte 0x03 is used to transform the sequences 0x000000, 0x000001, 0x000002 and 0x000003 into 0x00000300, 0x00000301, 0x00000302 and 0x00000303 respectively.
In each NAL unit the header occupies just the first byte of its sequence, the rest of the byte represents the actual payload.
The header contains information about the type of data contained in the payload, and it can divided in three parts.
The header 0x67 ( which is the header in your NAL unit ) for example corresponds to the binary sequence 0110 0111. The first bit of this sequence ( which is a 0 ) is the forbidden zero and is used to verify if errors where encountered during the transmission of the packet.
The following 2 bits ( the 11 ) are called nal_ref_idc and they indicates if NAL unit is a reference field, frame or picture.
The remaining 5 bits specify the nal_unit_type. It specifies the type of RBSP data structure contained in the NAL unit. For a more detailed explanation of the NAL unit header you can refer to table 7.1 found in here or to the official RFC

Change 1 bit in file. What I did wrong?

I had file with such content:
00 00 00 00 00
I had changed 1 bit. Changed file:
00 60 00 00 00
My teacher said, that I don't know what means bit. What I did wrong? Clarify this for me, please: file has 5 block (10 digits). Bit is 00? Or bit is 0 — 1 digit of pair. Thank you.
If this is in hexidecimal notation, then you have some terminology confusion.
00 00 00 00 00
|__| ^
\ |
byte nibble
A byte is two nibbles, and a nibble is 4 bits.
Decimal Hex Binary
0 0 0000 <- You went from here...
1 1 0001
2 2 0010
3 3 0011
4 4 0100
5 5 0101
6 6 0110 <- ...to here, a change in two bits of one nibble.
7 7 0111
8 8 1000
9 9 1001
10 a 1010
11 b 1011
12 c 1100
13 d 1101
14 e 1110
15 f 1111
That depends on what that notation means, but I'm assuming it's showing 5 bytes in hexadecimal notation.
These are bytes, 8 bit, in binary notation:
00000000
00000001
00000010
...
These are the same bytes in hexadecimal notation:
00
01
02
...
Hexadecimal notation goes from 00 to FF, binary notation for the same values from 00000000 to 11111111. If you changed 00 to 60, you changed 00000000 to 01100000. So you changed 2 bits.
You are viewing the file in a hex editor/viewer. Each digit is a hexadecimal digit consisting of four bits in binary. The fact that you went from 00 to 60 means that you changed two bits in one of the hex digits. If you were viewing in binary mode, you wouldn't see anything other than 0s and 1s.
hex 0 == binary 0000
hex 6 == binary 0110
I would recommend reviewing binary and hexadecimal notation.