Extended Pframe format

[QuantumEntangledAndy]

@thirtythreeforty @twistedddx

Thought I would start a discussion for this. Recently we have been getting media deserialisation errors for the newer argus 2 cameras.

I finally had time to parse the wireshark dump manually and I think I found it. It should perhaps merit discussion and @twistedddx may want to update his website with the info

---

First let me review our current understanding of the pframe format taken from @twistedddx website

01dc - 24 byte BC P frame header
4 bytes magic
4 bytes video type (eg H264 or H265)
4 bytes data size of payload after header
4 bytes unknown. Known values 1-00 2-00 3-00 4-00
4 bytes Microseconds
4 bytes unknown. Known values 1-00/5A 2-00 3-00 4-00

---

This is a header from a currently deseriable packet

magic	kind	size	unknownA	Microsecs	unknownB	end of header	payload
30316463	48323635	BC520000	00000000	18453300	00000000		00000001

---

This is a header from a currently packet that causes deserialisation failure. It does this by end of the payload being 8 bytes short of the next bcmedia packet

magic	kind	size	unknownA	Microsecs	unknownB	end of header	payload
30316463	48323635	1F420000	08000000	6ED25300	00000000		02000007 00000000 00000001

---

Now for conjecture and wild guesses

• A P/I frame usually starts with 00000001 but we can see in this example above that this start point is 8 bytes later than usual.
• Additionally this payload seems to miss off the final 8 bytes before the start of the next bcmedia (next is an aac packet fyi)
• We can also note that the unknownA has a value of 0x08000000 as in 8.

I think what is going on is that the unknownA signifies the length of extra data that is tacked onto the end of the header but before the payload.

I am not sure what the significance of 02000007 00000000 is however.

---

@thirtythreeforty @twistedddx Do you think that this is a credible interpretation? Do you have any idea what 02000007 00000000 could mean?

---

The following is the raw data for the undeseriable pframe (and the following aac packet):

un_deser_pframe.zip

[twistedddx]

Your guess looks reasonable to me.
Maybe the 08 does mean the header is extended 8 bytes.
I don't believe 02000007 00000000 is actual h265 data.

If I was encoding a video stream from a camera I would want to store the state of the hardware.
That way at playback you would know what physical things may have already altered the image.
Eg was the IR filter on/off, IR LEDs on/off, flood lights on/off, lux level, auto/manual start etc.
I haven't found such data stored within the BC video stream.

[QuantumEntangledAndy]

Could you count the number of bytes after the header until the next magic bytes? Then check it matches the payload size in the header ? That would let us know if something similar is happening.

[twistedddx]

I just sent an email with the captures.

From my camera captures I see no extra data between the expected header size and the start of h264 data.
I also do not see the 08 in my 01dc, only 00dc.
The 08 in the 00dc is consistent on all my cameras.
I think the 08 I see in my 00dc is not related to the 08 you currently see in that 01dc.

[QuantumEntangledAndy]

I see that's good to know. We can assume that these bytes are different things and not have to alter the current iframe implementation.

I'll try and get the users who have the camera that makes this pframe to test my fix and see if it generates any more odd data.

[twistedddx]

Maybe the header sizes could be exposed as a configurable setting that defaults to the current sizes.

Neolink could detect models in the future and adjust settings to known compatible settings.
Or the user could manually configure to override to something they know works for the model.

Compatibility settings that could be exposed:
00dcheadersize
01dcheadersize
01wbheadersize
05wbheadersize
encryptionmode eg 0,1,2
connectionmode eg TCP, UDP

[QuantumEntangledAndy]

We may need to add overrides for certain camera models at some point. It might not be easy t implement though. We'd need to pass this information from the top level all the way down to the serde code. Perhaps though the context data...

I'd prefer auto detection if at all possible though.

I think we have yet to find a direct conflict between the protocol as it seems that this unknown is zero in the pframe unless the header is larger. So no need to do this right now.

[QuantumEntangledAndy]

I would like to also post my thought on the iframe format since this is also extended:

This is a traditional header that we have seen to date:

magic	type	size	unknown A	ms	unknown B	time	unknown C
30306463	48323634	A3820B00	08000000	C015D29D	0A000000	1DAE1B61	0F00C300

The following is an newer extended iframe header

magic	type	size	unknown A	ms	unknown B	time	unknown C	unknown D	unknown E
30306463	48323635	77F60200	10000000	A143CFAA	47000000	53DBA761	3301C300	02000007	00000000

In the new packet unknownA is increased by 8 (from 8 to 16) and the size of the packet is increased by 8 bytes.

What I think is happening is that the normal size of a iframe header is actually 24 bytes exactly the same as the pframe. The reason we only every saw iframe header of size 32 was that all packets to date that we have recieved have had an unknownA of 8 and therefore had an extended size of (24+8) 32 bytes.

I therefore think that time & unknownC are actually optional header fields only permitable when unknownA >= 8 and that unknownA is the header extention size exactly the same as in the pframe.

[QuantumEntangledAndy]

@twistedddx do you have any examples where unknownA is zero for the iframe. I cannot find one on any of the dumps I have :(

[twistedddx]

I cannot find any example now with 00 for unknownA in iframe.
All mine show 08.

Maybe I was mistaken when I wrote down that I have ever seen a 00dc with a 00?
Or simply it is from an old firmware or device I no longer have examples from.

[QuantumEntangledAndy]

Thanks for looking anyways :). I believe that this representation of the i and pframes headers are correct but a zero unknowna would have really proven it.