avtp: crf: Extend tstamp with gst base and running time instead of CRF timestamp
The CRF time stamps also include the max transit time. Therefore a CRF time stamp can be greater than the AVTP presentation time stamp. This can result into an unexpected flip of the 32rd bit. To avoid such an issue the following rules have to be always true between reference time stamp used for extension and the time stamp to extend
- REFERENCE < TIMESTAMP
- REFERENCE > TIMESTAMP - 2^32ns
The following examples show what happens when those rules are not always guaranteed:
1. 0x16428124 0000 0001 REFERENCE time stamp (current_ts is used as reference without this patchset)
2. 0x16428124 0000 0000 expected 64 bit TIMESTAMP after extension (AVTP packet contains only lower 32 bits. Upper 32 bits have to be recovered correctly)
3. 0x16428124 0000 0000 after 32 bit to 64 bit extension
4. 0x16428125 0000 0000 after adding 2^32 because (TIMESTAMP[3] < REFERENCE[1])
=> NOT OK because rule 1 is violated (REFERENCE > TIMESTAMP)
1. 0x16428123 FFFF FFFF REFERENCE time stamp
2. 0x16428124 0000 0000 expected 64 bit TIMESTAMP after extension
3. 0x16428123 0000 0000 after 32 bit to 64 bit extension
4. 0x16428124 0000 0000 after adding 2^32 because (TIMESTAMP[3] < REFERENCE[1])
=> OK (recovered timestamp [4] matches expectation[2])
1. 0x16428123 0000 0000 REFERENCE time stamp
2. 0x16428124 0000 0000 expected 64 bit TIMESTAMP after extension
3. 0x16428123 0000 0000 after 32 bit to 64 bit extension
4. 0x16428123 0000 0000 2^32 will not be added because (TIMESTAMP < REFERENCE)
=> NOT OK because rule 2 is violated ((TIMESTAMP - REFERENCE) > 2^32ns)
1. 0x16428123 0000 0000 REFERENCE time stamp
2. 0x16428123 FFFF FFFF expected 64 bit TIMESTAMP after extension
3. 0x16428123 FFFF FFFF after 32 bit to 64 bit extension
4. 0x16428123 FFFF FFFF 2^32 will not be added because (TIMESTAMP < REFERENCE)
=> OK because (TIMESTAMP - REFERENCE) < 2^32ns
The first commit does not change the behavior. It is only refactoring some functions.