First off, please forgive my complete lack of knowledge in this field. I got some time ago a couple of really cheap wifi ip cameras that I was hoping to use on my local network. Unfortunately, it turned out the manufacturer (zmodo) had introduced about a year ago their own streaming protocol and had done away with the rtsp port present in previous models. The manufacturer supplied apps are only cloud based, which doesn't put me at ease. Luckily, people have been trying to come up with solutions to this and have been fairly successful with older models. So I tried to see what I can do myself.
In essence, the camera listens on port 8000 for 12 byte long commands. One of these commands triggers a stream of data. The data looks a little bit like a sequence of AVI chunks that start with either 00dc or 01dc. Just like in AVI, these tags are followed by a four-byte size (let's call it S) and 24 bytes that look like a time stamp (but could also contain more info). The total number of bytes between 00dc or 01dc tags is exactly 32 bytes more than S. So, we have something like this
30 30 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... S bytes of data that seems encrypted...
30 31 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... 00 00 00 01 61 .... S - 5 bytes of data...
The second type of chunk, prefixed by 01dc seems to contain unencrypted B- or P-frame NAL units (if my basic understanding is correct), but my question is about the first type. The first type probably contains I-frames but I cannot find a NAL delimeter or type byte. Additionally, the first 32 bytes of the S bytes of actual data are the same for every unit, i.e. I have
30 30 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... 32 constant bytes ... S-32 bytes of data
The camera also provides a 128 bit key which I naturally assumed to be for stream encryption (although it could be for cloud authentication or TLS or who knows what). So my question is, in your experience, which (encrypted) version of h.264 is this closest to? Any idea what the 32 constant bytes are?
EDIT: I am not sure that the keyframes are encrypted, I am only speculating. Actually, they seem to contain large areas of constant bytes at the end (although the bytes change from one unit to the next, i.e. e4 e4 .... e4 in one, then 93 93 .... 93, which rules out AES I think)
Related
I want to read and encode MIDI .mid files at the byte (and bit level). When reading through a .mid file, how do I recognize that a specific byte is the first byte of a delta time value?
For example, below is Figure 2.12 from Mandal's Multimedia Signals and Systems a diagram of a track chunk of a .mid file:
How do I know that the 01, 01, 78, 00, 00, and 00 are delta time bytes, given that the events they are attached to are of varying byte lengths? (For example, the instrument change appears to be two bytes beyond the delta time byte, while the first Note On event appears to contain 3 bytes beyond the delta time byte). Is it based on interpreting what follows the delta time byte? If so the fact that the second Note On event is throwing me: why does it appear to have only two bytes following the delta time byte?
It does not appear in Mandel's example, but I would appreciate an answer that clarified this for multi-byte delta times also.
And of course, I appreciate input on how to improve my question.
Finally, I am not asking for libraries that will automate reading .mid files. Those are good (yay!) but I want to understand the how to read the file format down to the byte level.
You indeed have to decoce a MIDI message before you know where the next delta time begins.
The actual Standard MIDI Files specification says:
<MTrk event> = <delta-time> <event>
<delta-time> is stored as a variable-length quantity. It represents the amount of time before
the following event. If the first event in a track occurs at the very beginning of a track, or if
two events occur simultaneously, a delta-time of zero is used. Delta-times are always present.
[…]
<event> = <MIDI event> | <sysex event> | <meta-event>
<MIDI event> is any MIDI channel message. Running status is used: status bytes of MIDI
channel messages may be omitted if the preceding event is a MIDI channel message with the
same status. The first event in each MTrk chunk must specify status. Delta-time is not
considered an event itself: it is an integral part of the syntax for an MTrk event. Notice that
running status occurs across delta-times.
When we want to transfer a single byte we send it as described in this screenshot.
When we transfer data in multiburst mode, we send address (of starting register) right after the acknowledge from slave instead of data. Then we send data and register address is automatically increment as shown in this book.
My question is that:
How Slave recognize that the byte, right after the first acknowledge, is address or data?
Hint: I used Google a lot but I couldn’t find an answer that would have satisfied me.
The slave can recognize the fact that the address spans over two bytes by checking the first address byte for a special bit pattern. A slave address beginning with the bit pattern of 1111 0 indicates a 10 bit address (as opposed to the regular 7 bit addresses) which spans over two bytes on the bus as defined in the I2C Bus Specification:
3.1.11 10-bit addressing
[...]
The 10-bit slave address is formed from the first two bytes following a START condition
(S) or a repeated START condition (Sr).
The first seven bits of the first byte are the combination 1111 0XX of which the last two bits
(XX) are the two Most-Significant Bits (MSB) of the 10-bit address; the eighth bit of the
first byte is the R/W bit that determines the direction of the message.
If the first address byte does not match the special bit pattern, the second byte would have to be treated as data.
So, in your example
| START | slave address | R/W | ACK | slave address | ACK | data | ...
| S | 1111 000 | 0 | A | 0000 1111 | A | 0000 0001 | ...
the master is reading multiple data bytes from a slave identified by the 10 bit address 00 0000 1111.
Im using matlab TCP connection to read the values of a stream data come from external device, the problem is when I used data=fscanf(t , "%d") where t is a TCP object, it reads a different number of values at each time, but I don't want it to do this, I want to read a 46 values at the same time.
Anyone have an idea?
To receive fixed size chunks of 46 values, use the size parameter of fscanf to receive not more than 46 values. Now this receiving has to be triggered only if enough data is available. Best practice is to use the BytesAvailableFcn. If configured with the correct size, it is triggered every time 46 values are available.
I have been having a heck of a time getting Udp sockets working correctly on Windows Phone 7 (Mango). First I had this problem udp async receive and now that I figured it out, I am seeing a weird behavior where the end of the data I send over the socket is all zero.
At first, I thought there was a weird size cap. All my packets were user 1380 bytes. I was seeing that for some reason, after ~byte 1220 it was all zeros, but according to the socket, I was still receiving all ~1380 bytes. I matched up the sizes with my server application, and I was receiving the correct number of byte. So I printed the bytes out on both sides of the connection and saw this issue with much of the last 200 bytes or so being zero.
So I reduced the size of my packet data to ~1200 bytes, and I was still seeing the issue. I even reduced it to 1000 bytes and still!
Any ideas?
Update - I have done some testing, and it seems that the last 144 bytes are FUBAR. Sometimes they are zero, sometimes they are garbage. Think this is a bug?
You need to check how many bytes were transferred in the async operation. Check SocketAsyncEventArgs.BytesTransferred to see how many bytes in the buffer are actually valid.
Sorry, I had a bug in my code where I was using an array over, overwriting my own data.
Hello i have made a program for my old windows mobile phone to send gps data ,temperature etc every 5 seconds just for experimental reasons to create a fleet management system.
I noticed that within one hour 350kb were consumed although i sent only 20kb of data...
As i dont have deep knowledge in networks ,how much does a tcp connection cost in bytes?
Maybe i should keep the socket alive because i close and open it every 5 seconds.Would that save bytes?
Also does MTU matter here?
Any other idea to reduce the overhead?
thank you
Let's do some math here.
Every 5 seconds is 720 connections per hour plus data. 20K / 720 is about 28 bytes of payload (your GPS data) for each connection.
IP and TCP headers along are 48 bytes in addition to whatever data is being sent.
3-way handshake connection: 3 packets (2 out, 1 in) == 96 bytes out and 48 bytes in
Outbound Data-packet: 48+28 bytes == 76 bytes (out)
Inbound Ack: 48 bytes (in)
Close: 48 bytes (out)
Final Ack: 48 bytes (in)
Total out per connection: 220
Total in per connection: 144
Total data send/received per connection: 220+144 = 364
Total data usage in one hour = 364 * 720 = 262K
So I'm in the ballpark of your data usage estimates.
If you're looking to reduce bandwidth usage, here's three ideas:
Scale back on your update rate.
Don't tear down the socket connection each time. Just keep it open.
Given your GPS coordinates are periodically updated, you could consider using UDP instead of TCP. There's potential for packet loss, but given you're retransmitting fresher data every 5 seconds anyway, an update getting lost isn't worth the bandwidth to retransmit. IP and UDP headers combined are only 28 bytes with no "connection" overhead.
UPDATE
When I originally posted this, I erroneously misunderstood the connection close to be a single exchange of FIN packets between client and server. In practice, the client sends a FIN as part of it initiating the CLOSE. Then server ACKs the FIN. Then the server sends its own FIN that is ACK'd by the client. In other words, an additional 96 bytes per connection. Redoing our math:
Total data send/received per connection =
220+48 + 144+48 = 460
Total data usage in one hour = 460 * 720 = 331K
So my revised estimate of 331KB in one hour is a bit closer to what the OP saw.