I'm trying to detect I-frames in TS by searching for the:
0x00 0x00 0x00 0x01 0x65
But, it doesn't work on some streams. In some streams this sequence occurs very rare. Is there any other way of detecting I-frames?
Edit:
I also tried saving TS to a file and then extracting H.264 payload. The extracted payload contains only a few 0x00 0x00 0x00 0x01 0x65 byte sequences.
What you are trying to do looks like a blind guess. H.264 specification is freely available. 00 00 00 01 is described in Annex B "Byte stream format" section. Then your 65 is what maps to section 7.3.1 "NAL unit syntax":
So you can split your byte stream into NAL units correctly and identify why your heuristic is not detecting I-Frames. Specifically, you are assuming two bit value to be equal to three exactly.
Also, slice types are defined as this:
See also:
Possible Locations for Sequence/Picture Parameter Set(s) for H.264 Stream
How to detect I/P/B frame from H264 RTP packet
Related
I have a APC SMC1000-2UC UPS device that has a serial port to connection. The serial port protocol seems that is based on microlink protocol which has not documented. I monitored the communication of the UPC and PC witch UPS deriver has been initialed. I want to detect command of UPS such as shutdown command by a microcontroller-based device. Some information of "https://sites.google.com/site/klaasdc/apc-smartups-decode" site is compatible with things I observed. but calculation of frame checksum and Challenge string calculation don't pass.
Data length of protocol has been set to 32 bytes, So each frame has 35 bytes.
[Msg ID | 32 byte data | 2 byte checksum]
Regarding calculation of challenge frame, the UPS send 0x65 frame ID then 0x68 frame ID, after that the PC response with 0x65 frame ID and UPS send confirmed frame by 0x65 frame ID. based on presented calculation, I think format or Position of Password_1, Header data and two bytes of that has been changed as the protocol has been configured to 32 bytes data. The following frame are a sample of this challenge:
Header frame: 0x00 0a206903fa27090001004000f802fe04fe0940fc1042fc1044fc20f80416fc10 32a6
UPS : 0x65 ffff00010000a0e80000 c0bbb4e1 000001040000001000000004000000000020 7350
UPS : 0x68 000000000000000000000008004c2943000000000966039a063b675601f30000 864f
PC : 0x65 0a 04 8afb65f1 bdf0
UPS : 0x65 ffff000100000eaf62d8 8afb65f1 000001040000001000000004000000000020 6227
How can I satisfy the challenge and checksum type? I try many type of checksum for that data but they not correct.
It may be a bit late, but have you looked at this:
https://github.com/klaasdc/apcups-serial-test
This looks like somebody got pretty far reverse engineering the MicroLink protocol, including the checksum part. The GitHub repo also contains a link to a web page with a protocol description.
I can't find any clue in H.264 spec, anybody can give a clear and simple maximum size regardless of its profile and level?
I'd like to parse H.264 stream, and copy one complete NAL unit buffer to a fixed-size buffer which can hold all bytes of one NAL unit.
Thanks.
AVC level 6.2 allows up to 139264 macro blocks per frame. If we use 10 bit color 4:4:4 it’s 30 bits per pixel. So (30*139264*16*16)/8 gives about 133.7mbytes for an uncompressed image. H.264 has a PCM_I encoding that allows for uncompressed images. There is a little ovehead for the NAL header, so let’s call it 134Mbyte. But in the real world the frame probablly will not be this large, and will likely be compressed.
I don't think there is a maximum for video NALs. In Annex-B format the NALs are start code delimited 0x00 0x00 0x00 0x01 so there is no limitation through a size field. In MP4 format the size field can have more capacity than most computer's RAM. I'd make a reasonable assumption what buffer size to expect and then reallocate if the maximum is exceeded.
I have general question about the usage of start code (0x00 0x00 0x00 0x01) for the H264 video. I am not clear about the usage of this start code as there is no reference in the RTP RFCs that are related to H264 video. But I do see lot of reference in the net and particularly in the stackoverflow.
I am confused as I see one client doesn't have this start code and another client is using this start code. So, I am looking for a specific answer where this start code should be used and where I shouldn't.
KMurali
There are two H.264 stream formats and they are sometimes called
Annex B (as found in raw H.264 stream)
AVCC (as found in containers like MP4)
An H.264 stream is made of NALs (a unit of packaging)
(1) Annex B : has 4-byte start code before each NAL unit's bytes [x00][x00][x00][x01].
[start code]--[NAL]--[start code]--[NAL] etc
(2) AVCC : is size prefixed (meaning each NALU begins with byte size of this NALU)
[SIZE (4 bytes)]--[NAL]--[SIZE (4 bytes)]--[NAL] etc
Some notes :
The AVCC (MP4) stream format doesn't contain any NALs of type SPS, PPS or AU delimter. Since that specific information is now placed within MP4 metadata.
The Annex B format you'll find in MPEG-2 TS, RTP and some encoders default output.
The AVCC format you'll find in MP4, FLV, MKV, AVI and such A/V container formats.
Both formats can be converted into each other.
Annex B to MP4 : Remove start codes, insert length of NAL, filter out SPS, PPS and AU delimiter.
MP4 to Annex B : Remove length, insert start code, insert SPS for each I-frame, insert PPS for each frame, insert AU delimiter for each GOP.
I'm using the H264 encoder from Media Foundation (MFT). I extracted the SPS and PPS from it, because I need it for smooth streaming. The MSDN says that the number of bytes used for the length field that appears before each NALU can be 1, 2, or 4. This is all in network byte order. As you can see, the first 4 bytes in the buffer are 0, 0, 0, 1. If we apply any of the possible lengths, we will get nothing. If the number of bytes used for length is 1, then the length is zero, if it is 2, the length is zero again. If it is 4, the length of first NALU is 1?! And, that's not correct. Does anybody know how should I interpret this SPS and PPS concatenated together??
The answer here is simple: the data is valid and formatted according to Annex B, prefixed by start codes 00 00 00 01 and not run length encoding.
H.264 extradata (partially) explained - for dummies
Annex B format
in this format, each NAL is preceeded by a four byte start code: 0x00
0x00 0x00 0x01 thus in order to know where a NAL start and where it
stops, you would need to read each byte of the bitstream, looking for
these start codes, which can be a pain if you need to convert between
this format and the other format.
More details on H.264 spec - freely available for download. Page 326 starts with "Annex B - Byte stream format".
I am using OpenGTS for some time for my organization. I was using TK103 family tracker but now my company changed tracker and brought GT06 made by Shenzhen Concox Information Technology Co. Ltd. This tracker protocol is entirely different and I am unable to create its server. Can anyone help me for this tracker integration or let me know which already integrated tracker is somehow similar to this one. Just give me a tip and I will manage rest. I am copying some protocol for your reference.
5.1.3. Examples
Examples of the login message packet sent by the terminal to the server and the response packet sent by the server to the terminal are as follows: (in the examples the terminal ID is 123456789012345.
Example of data packet sent by the terminal 78 780 0D 01 01 23 45 67 89 01 23 45 00 01 8C DD 0D 0A
Example of response packet returned by the server
78 78 05 01 00 01 D9 DC 0D 0A
Shenzhen Concox Information Technology Co.,Ltd www.cothinking.net/
Copyright Reserved.
5.2. Location Data Packet (combined information package of GPS and LBS)
5.2.1. Terminal Sending Location Data Packet to Server
Format Length(Byte) Example
Start Bit 2 0x78 0x78
Packet Length 1 0x1F
Protocol Number 1 0x12
Date Time 6 0x0B 0x08 0x1D 0x11 0x2E 0x10
Quantity of
GPS
information
satellites
1 0xCF
Latitude 4 0x02 0x7A 0xC7 0xEB
Longitude 4 0x0C 0x46 0x58 0x49
Speed 1 0x00
GPS
Information
Course,
Status
2 0x14 0x8F
MCC 2 0x01 0xCC
MNC 1 0x00
LAC 2 0x28 0x7D
LBS
Information
Cell ID 3 0x00 0x1F 0xB8
Serial Number 2 0x00 0x03
Error Check 2 0x80 0x81
Information
Content
Stop Bit 2 0x0D 0x0A
You can use Traccar server to track GT06 devices. It can be used as stand alone tracking system or if you prefer OpenGTS you can easily integrate two systems (use OpenGTS web interface and Traccar for device communication). Configuration file for integrating Traccar and OpenGTS can be found here.
the GT06 protocol is different from the tk103.
the 4th byte (0x01) indicates a login protocol call for tracker with IMEI 01 23 45 67 89 01 23 45 (remove first zero).
it should be answered and the socket kept open. you will receiva a 0x13 or 0x12 message (probably).
a 0x12 message has GPS location data.
i expect that you are not doing this blindfolded. if needed, refer to coding protocol manual. please note that some discrepancies may appear between concox and robustel units, even though both are variants of the original GreenTel GT06.