Vinden synchronisatie byte in datastroom

[Verwijderd]

Bij het uitlezen van een datastroom krijg ik pakketjes van 188 bytes binnen.
Elk compleet pakketje bestaat uit achtereenvolgens een header en een payload.
Elke header begint met een sync byte (0x47).

Het uitlezen van de stroom per pakketje gaat goed zolang er geen fouten in de stroom zitten. Als er wel een fout in zit merkt het programma dat omdat de eerste byte van een pakketje in de stroom niet 0x47 terug geeft. Als dit het geval is zou je dus vanaf de vorige (laatste) goede sync byte moeten zoeken naar de eerst volgende goede sync byte.

Nou kan ik bijvoorbeeld na 90 bytes een byte met waarde 0x47 tegenkomen maar hoe weet ik nou zeker of dit een sync byte is en niet bijvoorbeeld een byte uit de payload?

Is hier een standaard methode of oplossing voor? Ik heb al gezocht onder mpeg stromen maar ik kom hier nergens een goede oplossing voor tegen. De enige (niet waterdichte) oplossing die ik zo kan bedenken is dat als een 0x47 byte is gevonden ook meteen 188 bytes verder te kijken om te zien of deze ook 0x47 is.

[pjvandesande]

Je weet natuurlijk dat er 1 0x47 byte moet zijn en over 188 bytes weer. Dus is er 1 eerder kun je er vanuit gaan dat dat een goed pakketje is, mits die ook 188 bytes lang is.

[Tomatoman]

Enkel op basis van de sync byte kun je als het aantal binnengekomen bytes niet klopt op geen enkele manier met 100% zekerheid weer synchroniseren met een volgende header. Ga maar eens van een datastroom uit die heel toevallig voornamelijk uit 0x47 bytes bestaat. Wat is dan de sync byte? Onmogelijk daar een antwoord op te geven.

Wil je op basis van die ene header byte weer synchroniseren, dan kan dat alleen 100% betrouwbaar als je zeker weet dat er geen bytes zijn weggevallen of ingevoegd. Afhankelijk van het headerformaat kun je echter wel met (iets) minder dan 100% betrouwbaarheid de volgende sync byte vinden.

Dan kun je proberen de eerste 0x47 byte die je tegenkomt in de datastroom te interpreteren als de sync byte van de header. Vervolgens interpreteer je de volledige header. Als dat goed gaat, zit je blijkbaar weer op het goede spoor. Is alles wat er achter die sync byte aankomt geen header, dan probeer je het opnieuw met de volgende 0x47 byte, net zolang tot je een header te pakken hebt.

Mocht er in die header ook een checksum verstopt zitten, dan is dit trial-and-error zoeksysteem trouwens een stuk betrouwbaarder, omdat de kans dat een checksum voor een pakketje 'toevallig' klopt wel erg klein is. Wil je nog wat meer zekerheid inbouwen, dan kun je als extra eis stellen dat twee achter elkaar volgende pakketjes allebei een geldige checksum hebben. Is dat niet het geval, dan is een van beide checksums onjuist of had je blijkbaar geen sync byte te pakken - in beide gevallen zoek je vrolijk verder naar een geldige sync byte.

[Verwijderd]

Oke bedankt. Het is niet zo heel erg dat het niet waterdicht is maar ik wilde toch even weten of de mogelijkheid er was. Een checksum is er niet dus dat vervalt ook.

[Sjaaky]

Dit klinkt als een mpeg2 transport stream.
Het programma vlc (video lan client) controleert voor de synchronisatie de 4 achtereenvolgende syncbytes. Als dit klopt wordt de stream als gesynchroniseerd beschouwd en gaat vlc video decoden. In de praktijk werkt dit goed. Uiteindelijk kun je ook niet onbeperkt blijven kijken waar de syncbytes zitten, maar moet je gewoon video laten zien.

ps. Ik ben benieuwd naar het grotere geheel waar je mee bezig bent.