zzzzzz

Iemand zei mij dat mijn test niet klopte, omdat ik OpenPLi getest had op een Dreambox 8000 en VTI op een VU+ Duo 4K, en dat de filestructuur daardoor anders zou kunnen zijn.

Dus heb ik de test nog eens herhaald op de VU+ Duo 4K.

Natuurlijk kan ik dan niet gelijktijdig dezelfde opname maken van dezelfde zender om te zien of de structuur anders is, maar ik denk dat we er mogen vanuit gaan, dat die structuur niet op 10 minuten tijd weer helemaal verandert, zeker als het dezelfde zender is.

Ik heb dus nog eens een gecodeerde opname gemaakt van 2 minuten in VTI, deze is te decoderen, en ook af te spelen.
Daarna heb ik OpenPLi geflasht (de laatste stable release van 17 oktober 2021), en van dezelfde zender heb ik nog eens een gecodeerde opname gemaakt, opnieuw van dezelfde zender, en opnieuw van 2 minuten.

OpenPLi kon zijn eigen opname niet offline decoderen, maar wel afspelen.

OpenPLi kon de opname van VTI niet offline decoderen en ook niet afspelen.

Omgekeerd kon ik de opname van OpenPLi wel nog afspelen in VTI, maar hij kon ze niet offline decoderen.  

De gecodeerde files heb ik ook nog eens geanalyseerd met de TSDuck tools.

Mijn bevindingen blijven dus overeind.

Bij VTI worden de CAT en de TOT/TDT als globale PIDs in de .TS file opgeslagen, waar ze als service specifiek gezien worden in OpenPLi.

Ik vermoed dat daar het verschil zit tussen offline decoderen en in real time afspelen.

De routines die offline decoderen zoeken waarschijnlijk naar de CAT in de globale PID's, vinden die niet, en doen dan maar verder, en dan heb je uiteindelijk een file die even gecodeerd is waarvan je vertrokken bent.

Bij gewoon afspelen zal hij dan wel de service specifieke gebruiken.

Eventueel kan het ook aan die timestamps liggen, die er bij VTI inzitten en niet bij OpenPLi.

De kernelversie van VTI is : 

4.1.45-1.17 #1 SMP Thu Sep 10 17:29:45 CEST 2020

Een paar fragmentjes uit die logfiles van TSDuck :