From: CugelOm terug te komen op Daan's opmerking; 16 films tegelijk draaien vergt net zoveel CPU bellasting
als één film...het is maar net hoe je het scherm indeelt. Wij hebben dat ook voor elkaar gekregen
destijds met de voorloper van PIP. Niet meer dan 20 tuners hebben we gebruikt en maar één input
signaal (via coax). Het concept van de decoder die we gebouwd hebben bestaat nu nog en de chipkaart
geeft je toegang tot een aantal kanalen. (De)compressie was toen gewoon de gehele bandbreedte
maximaal gebruiken. Naar mijn mening kan Jan niet meer hebben gedaan dan de fase verschuiving
van de "draaggolf" softwarematig in 16 stukjes te delen. Zie één film in de vorm van een helix
die het signaal vormt maar Jan kreeg het voor elkaar omdat destijds al te vermeerderen naar 16 films.
Hoe hij onderling dan toch nog sommige films op een andere snelheid heeft weten te krijgen weten we niet.
Daar heeft hij waarschijnlijk een heel groot parallel werkgeheugen voor gebruikt. Een saillant detail is altijd
wel geweest dat niemand ooit heeft geproken over dat ze 16 hele films hebben gezien.
Het enige wat mogelijk is is dat die 16 films wel degelijk op één schijf stonden.
De eerste film wordt opgenomen en de software volgt gewoon de naar binnen buiten beweging.
De volgende fims die opgeslagen worden volgen de data maar om dat kloppende te houden moeten
er minimaal 5 logaritmen de koers bijhouden van de film. Ik denk dat die koers de compressie is geweest.
Gewoon een heel andere kijk op data tracing.
Of de films waren al opgeslagen op een schijf maar niet zoals we CD of DVD kennen met enen en nullen.
Maar als het ware als in een trapsgewijze groef van zeg 8 lagen diep, totaal dus overdwars gezien 16 tracks.
Vanaf twee kanten gelezen heb je dus al 32 tracks, en dan heb ik het alleen nog maar over een horizontale
scan, doe je dit ook vertikaal dan heb je al 64 tracks...altijd weer die pi ram ide van Gizeh