curioustorvald/tsvm
1
0
Fork 0
mirror of https://github.com/curioustorvald/tsvm.git synced 2026-03-07 11:51:49 +09:00
Code Issues Packages Projects Releases Wiki Activity

TAV-DT format revision and soft sync recovery

Browse Source
This commit is contained in:
minjaesong
2025-12-15 17:42:08 +09:00
parent 3d76006ad9
commit 4929d84cec
4 changed files with 189 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
terranmon.txt
View File

@@ -1647,9 +1647,9 @@ start of the next packet
* Quality indices follow TSVM encoder's
int16 Reserved (zero-fill)
uint32 Total packet size (sum of TAD packet and TAV packet size)
uint32 CRC-32 of [sync pattern + framerate + flags + reserved + total packet size]
uint64 Timecode in nanoseconds
uint32 Offset to video packet
uint32 CRC-32 of [sync pattern + framerate + flags + reserved + total packet size + timecode + offset]
<packet header end; encoded with rate 1/2 LDPC>
bytes TAD with forward error correction
<TAD header start>
@@ -1688,7 +1688,24 @@ start of the next packet
6. If they match, sync to the stream; if not, find a next sync pattern
7. "Offset to video packet" and the actual length of the TAD packet can be used together to recover video packet when stream is damaged, using the fact that in error-free stream, length of TAD packet is equal to "Offset to video packet", and the internal packet order is always audio-then-video
The decoder "may" try to sync to the sync pattern that appears damaged when its contents are seem to be intact.
## Soft Sync Recovery
The decoder MAY try to sync to the sync pattern that appears damaged when its contents are seem to be intact, under the following strategies.
### Stage 1
On the stream position where the sync pattern is supposed to be:
1. Substitute damaged sync pattern with known sync pattern (videos are not allowed to change NTSC/PAL mode mid-stream, so there's only one known value)
2. Zero-fill the reserved area if haven't already
3. Re-calculate CRC. If match, sync. If not, head to the next stage
### Stage 2
1. Further substitute the framerate, flags, timecode to the last known value (as these values rarely change mid-stream; timecode must be incremented appropriately. e.g. FPS=16, last known timecode=5.0, packets missed so far=4, then assumed timecode is 5.0 + 4 + 1 = 10.0)
2. Re-calculate CRC. If match, sync. If not, soft sync recovery is failed, and discard the packet
Note: If CRC is unmatched, the packet MUST be discarded, as the header content cannot be trusted if all soft recovery stages have failed
--------------------------------------------------------------------------------