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.
Related
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.
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
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
so i'm running CentOS 6, and after enabling large-pages in mysql, i restart the service and get this, and mysql fails to start:
kernel:Oops: 0003 [#1] SMP
kernel:Stack:
kernel:Call Trace:
kernel:Code: 00 e8 53 4f 02 00 48 89 c7 e8 0b f1 ff ff 48 8d 7d e0 48 89 45 e0 48 89 5d e8 e8 60 fe ff ff bf 01 00 00 00 e8 aa f7 ff ff eb 03
kernel:CR2: ffff8800dc2fe330
After removing the offending line from the config file, I still have to reboot before it'll start again. Thoughts?
Did you enable large pages as described here?
http://dev.mysql.com/doc/refman/5.0/en/large-page-support.html
An easy way to check is: cat /proc/meminfo | grep 'Huge'
In addition via sysctl the following should be set
vm.hugetlb_shm_group=27
(If 27 is the ID of user mysql)
While I was working with an old application with existing database which is in ms-access contains some strange data encoding such as 48001700030E0F465075465A56525E1100121D04121B565A58 as email address
What kind of data encoding is this? i tried base64 but it dosent seems that. Can anybody with previous experience with ms-access could tell me what possible encoding could this be.
edit:
more samples
54001700030E0F46507546474550481C1D09090D04461B565A195E5F
40001700030E0F4650755F564E545F06025D100E0C
38001700030E0F4650754545564654155C101C0C
46001700030E0F4650755D565150591D1B0007124F565A58
above samples are surely emails and for web url it looks like this
440505045D070D54585C5B50585D581C1701004F025A58
440505045D121147544C5B584D4B5D17015D100E4F5C5B
This is vb + ms access program if that can be any help and i think it some standard encoding
edit (2) ::
from looking at web url encoding it seems 0505045D could be for http://
edit(3) ::
1 combination found
52021301161209755354595A5E5F561D170B030E1341461B56585A == paresh#falmingoexports.com
It appears to be bytes encoded as hexadecimal. But what those bytes mean, I don't know. Decoding it to ASCII doesn't reveal much:
H \x00\x17\x00\x03\x0e\x0fFPu FZVR^ \x11\x00\x12\x1d\x04\x12\x1bVZX
T \x00\x17\x00\x03\x0e\x0fFPu FGEPH \x1c\x1d\t\t\r\x04F\x1bVZ\x19^_
# \x00\x17\x00\x03\x0e\x0fFPu _VNT_ \x06\x02]\x10\x0e\x0c
8 \x00\x17\x00\x03\x0e\x0fFPu EEVFT \x15\\\x10\x1c\x0c
F \x00\x17\x00\x03\x0e\x0fFPu ]VQPY \x1d\x1b\x00\x07\x12OVZX
Things I've noticed that may help crack the code:
The 2nd to 10th bytes appear to constant \x00\x17\x00\x03\x0e\x0fFPu.
The first byte is BCD length (spotted by Daniel Brückner!)
16th bytes onwards appear to some binary format that either encode the data or perhaps a pointer to the data.
Two of them end in: \x12?VZX.
The strings seem to be hexadecimal representations of some binary data.
The first two digits are the length of the string - decimal, not hexadecimal - so not the entire string is hexadecimal.
38 001700030E0F465075 4545 5646 5415 5C10 1C0C
40 001700030E0F465075 5F56 4E54 5F06 025D 100E 0C
46 001700030E0F465075 5D56 5150 591D 1B00 0712 4F56 5A58
48 001700030E0F465075 465A 5652 5E11 0012 1D04 121B 565A 58
54 001700030E0F465075 4647 4550 481C 1D09 090D 0446 1B56 5A19 5E5F
^ ^
| |
| +---- constant part, 9 bytes, maybe mailto: or same domain name of
| reversed email addresses (com.example#foo)
|
+---- length of the reset in decimal, not hexadecimal
I can see no clear indication for the location of the at-sign and the dot before the top-level domain. Seems to be an indication against simple mono-alphabetic substitutions like ROT13.
paresh#falmingoexports.com
Length
26 characters
Histogram
1x
h # f l i n g x t . c
3x o
2x p 2x a 2x m 2x r 2x e 2x s
ASCII values in hexadecimal representation
70 61 72 65 73 68 40 66 61 6C
6D 69 6E 67 6F 65 78 70 6F 72
74 73 2E 63 6F 6D
The length of 52 hexadecimal symbols matches length of the
encoded string.
52 02 13 01 16 12 09 75 53 54 59
5A 5E 5F 56 1D 17 0B 03 0E 13
41 46 1B 56 58 5A
Histogram
1x
01 02 03 09 0B 0E 12 16 17 1B
1D 41 46 53 54 58 59 5E 5F 75
2x 13 2x 56 2x 5A
The histograms don't match - so this rules out mono-alphabetic substitutions possibly followed by a permutation of the string.