-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/SD Card #104
base: master
Are you sure you want to change the base?
Feature/SD Card #104
Conversation
First the client requests the HDDInfoList with message ID 0x66 The camera replies with: If no SD Card: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<HddInfoList version="1.1" />
</body> If there is a SD Card <?xml version="1.0" encoding="UTF-8" ?>
<body>
<HddInfoList version="1.1">
<HddInfo>
<number>0</number>
<capacity>30</capacity>
<format>1</format>
<mount>1</mount>
<remainSize>29</remainSize>
<remainSizeM>551</remainSizeM>
</HddInfo>
</HddInfoList>
</body> |
Client then requests day records with msg ID: 0x8e and the payload: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<DayRecords version="1.1">
<startTime>
<year>2023</year>
<month>6</month>
<day>1</day>
<hour>0</hour>
<minute>0</minute>
<second>0</second>
</startTime>
<endTime>
<year>2023</year>
<month>6</month>
<day>30</day>
<hour>23</hour>
<minute>59</minute>
<second>59</second>
</endTime>
<DayRecordList>
<DayRecord>
<index>0</index>
<channelId>0</channelId>
</DayRecord>
</DayRecordList>
</DayRecords>
</body> Client replies with: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<DayRecords version="1.1">
<startTime>
<year>2023</year>
<month>6</month>
<day>1</day>
<hour>0</hour>
<minute>0</minute>
<second>0</second>
</startTime>
<endTime>
<year>2023</year>
<month>6</month>
<day>30</day>
<hour>23</hour>
<minute>59</minute>
<second>59</second>
</endTime>
<DayRecordList>
<DayRecord>
<index>0</index>
<channelId>0</channelId>
<dayTypeList>
<dayType>
<index>6</index>
<type>normal</type>
</dayType>
<dayType>
<index>7</index>
<type>normal</type>
</dayType>
<dayType>
<index>8</index>
<type>normal</type>
</dayType>
</dayTypeList>
</DayRecord>
</DayRecordList>
</DayRecords>
</body> This seems to reply with indexes where 0 is the 0th day from the range chosen. So in this case as the range starts with 01/06 then the indexes 6, 7 and 8 correspond to the days 7th, 8th and 9th of June |
Next the client requests FileInfoList with msg ID 0x0e and the payload: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FileInfoList version="1.1">
<FileInfo>
<channelId>0</channelId>
<streamType>subStream</streamType>
<recordType>manual, sched, io, md, people, face, vehicle, dog_cat, visitor</recordType>
<startTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>0</hour>
<minute>0</minute>
<second>0</second>
</startTime>
<endTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>23</hour>
<minute>59</minute>
<second>59</second>
</endTime>
</FileInfo>
</FileInfoList>
</body> This payload picks up one of the days from the above DayRecords The camera replies with: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FileInfoList version="1.1">
<FileInfo>
<channelId>0</channelId>
<handle>1</handle>
<name></name>
<recordType>manual, io, md, sched</recordType>
<supportSub>1</supportSub>
<sizeL>0</sizeL>
<sizeH>0</sizeH>
<startTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>0</hour>
<minute>0</minute>
<second>0</second>
</startTime>
<endTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>23</hour>
<minute>59</minute>
<second>59</second>
</endTime>
</FileInfo>
</FileInfoList>
</body> This gives a |
The client then requests FileInfoList on message ID 0x0f with the payload: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FileInfoList version="1.1">
<FileInfo>
<channelId>0</channelId>
<handle>1</handle>
</FileInfo>
</FileInfoList>
</body> This uses the handle from before The camera replies with: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FileInfoList version="1.1">
<FileInfo>
<channelId>0</channelId>
<handle>1</handle>
<name>0120230609072812</name>
<streamType>subStream</streamType>
<containsAudio>1</containsAudio>
<fileType>mp4</fileType>
<recordType>md</recordType>
<sizeL>2100542</sizeL>
<sizeH>0</sizeH>
<supportSub>1</supportSub>
<startTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>28</minute>
<second>12</second>
</startTime>
<endTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>28</minute>
<second>39</second>
</endTime>
</FileInfo>
<FileInfo>
<channelId>0</channelId>
<handle>1</handle>
<name>0120230609073619</name>
<streamType>subStream</streamType>
<containsAudio>1</containsAudio>
<fileType>mp4</fileType>
<recordType>md</recordType>
<sizeL>2605156</sizeL>
<sizeH>0</sizeH>
<supportSub>1</supportSub>
<startTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>36</minute>
<second>19</second>
</startTime>
<endTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>36</minute>
<second>52</second>
</endTime>
</FileInfo>
<FileInfo>
<channelId>0</channelId>
<handle>1</handle>
<name>0120230609073919</name>
<streamType>subStream</streamType>
<containsAudio>1</containsAudio>
<fileType>mp4</fileType>
<recordType>md</recordType>
<sizeL>5097061</sizeL>
<sizeH>0</sizeH>
<supportSub>1</supportSub>
<startTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>39</minute>
<second>19</second>
</startTime>
<endTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>40</minute>
<second>27</second>
</endTime>
</FileInfo>
<FileInfo>
<channelId>0</channelId>
<handle>1</handle>
<name>0120230609074023</name>
<streamType>subStream</streamType>
<containsAudio>1</containsAudio>
<fileType>mp4</fileType>
<recordType>md</recordType>
<sizeL>8586753</sizeL>
<sizeH>0</sizeH>
<supportSub>1</supportSub>
<startTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>40</minute>
<second>23</second>
</startTime>
<endTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>42</minute>
<second>30</second>
</endTime>
</FileInfo>
<FileInfo>
<channelId>0</channelId>
<handle>1</handle>
<name>0120230609074226</name>
<streamType>subStream</streamType>
<containsAudio>1</containsAudio>
<fileType>mp4</fileType>
<recordType>md</recordType>
<sizeL>364907</sizeL>
<sizeH>0</sizeH>
<supportSub>1</supportSub>
<startTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>42</minute>
<second>26</second>
</startTime>
<endTime>
<y�·wGûæIKNó3«SX(ä±Lv[æìNZ
Pó½Q2[RóYØXGÚYç_Q§[ýPGn¨mîPGj¨WîXGÞYØRRù¦pªH¡VMPâ4§AXlQâ W2OG¨mîZP¤WàZI[G÷ì)Z�MLâìZIOMøºlZFCïYëIC[¨mîK P¡[ýK P[¿JVG¨TëI�KLã·lZQGõ¼GXW¹·@ F[ýPPV¿FXlGøJ�(ª·BX¤TîCP¨mîN VJ¨Qî� LVþYØ[¯[ýG(ª½VX¹½VX(û¼V¦[ýNWVóYØAMøìQZ
Qó½MX(¹¼G2OG¨mî NGß ´LXldÿ�·jM[±KLGú.¶VZ
Aþ¼M
kF¨mîKFNóYãICLò�·lZLCûìWT¥Wä_V¦UáICOóYØPG÷
ZQãWCOªH¡WCO¢FXlAù ¦BQcã»LXW
õ¼WLQ׶J X(ð¾F2RG¨
¢ZIDKúZ(ª·@ Fvï·�
ä±Lv[æì)ZKXó+ìS^£TîXGÚYØXGÞYâIKXó/ì)ZWRæ W5@§[ýPRMäVX(å³Q2KOóYØCP¨UâUZ
[ó l This is the largest XML record to date and the current decrytor used in wireshark is FAILING. There may be some refinements needed in order to decrypt large messages like this |
The client then sends a FileInfoList on msg ID 0x10 with the payload: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FileInfoList version="1.1">
<FileInfo>
<channelId>0</channelId>
<handle>1</handle>
</FileInfo>
</FileInfoList>
</body> The camera just replies with the standard 200 status OK header No idea what this is for. Seems to be the same as 0x0f but with no real reply from the camera. Maybe its for a different type of data storage or file type that I don't have |
Client then sends ReplaySeek on msgID 0x7b with the payload: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<ReplaySeek version="1.1">
<channelId>0</channelId>
<seq>1686278241</seq>
<seekTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>28</minute>
<second>12</second>
</seekTime>
</ReplaySeek>
</body>
Camera replies with standard OK header |
The client then sends FileInfoList on msg ID 0x0d with payload: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FileInfoList version="1.1">
<FileInfo>
<channelId>0</channelId>
<name>0120230609072812</name>
<supportSub>1</supportSub>
<playSpeed>1</playSpeed>
<streamType>subStream</streamType>
</FileInfo>
</FileInfoList>
</body> This uses the name from the 0x0f FileInfoList Camera replies with <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FileInfoList version="1.1">
<FileInfo>
<channelId>0</channelId>
<handle>0</handle>
<name>0120230609072812</name>
<containsAudio>1</containsAudio>
<fileType>mp4</fileType>
<recordType>none</recordType>
<sizeL>2100542</sizeL>
<sizeH>0</sizeH>
<supportSub>1</supportSub>
<startTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>28</minute>
<second>12</second>
</startTime>
<endTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>28</minute>
<second>39</second>
</endTime>
</FileInfo>
</FileInfoList>
</body> This seems to give details such as the file size and type |
Now we get to the actual data. This is done though the FileInfoList command again... with the msg ID 0x05 and the payload: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FileInfoList version="1.1">
<FileInfo>
<channelId>0</channelId>
<supportSub>1</supportSub>
<streamType>subStream</streamType>
<startTime>
<year>2023</year>
<month>6</month>
<day>9</day>
<hour>7</hour>
<minute>28</minute>
<second>12</second>
</startTime>
<playSpeed>1</playSpeed>
</FileInfo>
</FileInfoList>
</body> This seems to just be a play start time rather then a file, I presume the other commands before were about loading the file and preparing it for this There are multiple messages from the camera now and things got weird.. I'll show the whole header so we can see it Firstly this one:
Is a normal header and the first packet from the camera in reply to FileInfoList 0x05 It has the extension of <?xml version="1.0" encoding="UTF-8" ?>
<Extension version="1.1">
<binaryData>1</binaryData>
</Extension> Followed by a binary payload in BCMedia format. This it the format that the camera uses for everything (it's not a mp4 like the FileInfoList data says) fortunaly we already know how to decode these as they are used for the live stream. The packets after this get weird though
That status is no longer the usual status code stuff but instead the number 1686278241, So lets rename this as
This actually brings about another issue. The current neolink implementation The payload for this is the extension xml <?xml version="1.0" encoding="UTF-8" ?>
<Extension version="1.1">
<binaryData>1</binaryData>
</Extension> with the continue binary BCMedia stream This packet repeats indefintly until the whole stream is finished (the seconds header remains the same number throughout) |
The last message comes from the client as FileInfoList with id 0x07 and the payload <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FileInfoList version="1.1">
<FileInfo>
<channelId>0</channelId>
<name>0120230609072812</name>
</FileInfo>
</FileInfoList>
</body> The camera just replies OK with the standard header This seems to be the STOP command for the replay |
Those are the messages that need to be implemented and sent. The difficult one will come with the reworking of the message class. We may no longer be able to relay on it as a source of the message format. May need to rework how this is implemented. Maybe with different header kinds as a enum May take awhile to redo and I will wait for the other current PRs to close as it will likely need a refractor |
I'm willing to help, if I could, on this. I have 4 Argus 2 in use, and could setup may one for permanent test during Development. |
Just busy with work at the moment. If you can code rust it might be helpful if you could work up a basic PR for at least the messages structures I think it's in |
I have no knowledge in rust. Only in other languages, but I'm more a script Copy paste guy ;) So not sure, if I could help in that. I had a short look to the xml, but this looks like not so clear to me. |
This will RE the SD card and file listing features of the camera