Grote binary files bewerken

[Verwijderd]

Ik ben bezig met een projectje om transport streams te bewerken. Ik weet dat dergelijke software bestaat maar dan leer ik weer weining

In het begin ging het om kleinere files die volledig in het geheugen konden worden geladen. De reden voor het gebruik van geheugen is, is dat het gevoelsmatig sneller is (slechts eenmalig inlezen) als de file eenmaal is ingelezen. Maar nu zijn de files groter (1GB +) en loop ik tegen de geheugen limieten van de PC aan De work-around hiervoor is momenteel om files slechts gedeeltelijk in te lezen.

Ik vind de work-around niet echt jofel en dus moet dit op de schop en ik heb wat ideeen nodig om dit efficient aan te pakken.

Het bewerken van bestaande pakketten (en vervolgens weer terugschrijven naar de file) denk ik wel te kunnen oplossen (met een seek of zo). Het grote probleem is wat ik moet doen als pakketten worden verwijderd of toegevoegd. Hoe doen (hex) editors dit die grote hoeveelheden data kunnen bewerken?

Ik heb wat gezocht, maar nog geen oplossing hiervoor gevonden; waarschijnlijk de verkeerde zoektermen gebruikt

Aanwijzingen waar ik naar moet zoeken en/of hoe ik dit moet aanpakken worden op prijs gesteld.

WimS

PS Dit wordt geschreven in C# (voor Windows).

[Onbekend]

Ik neem aan dat van tevoren weet welke data je weg gaat schrijven. Dus niet dat je achteraf pas weet dat je iets in de eerste byte nog wil aanpassen.

In dat geval zou ik gewoon met 2 (file)streams gaan werken. Met de eerste lees je het bestand uit, en met de tweede schrijf je het bestand weg. Je hoeft dus gewoon niet het complete bestand in te laden.

[Hydra]

Het is me niet duidelijk of je een soort editor maakt (die dus zaken in het geheugen moet houden om te tonen aan de gebruiker) of gewoon een tool die volledig automatisch een file moet bewerken. In het laatste geval kun je gewoon met filestreams werken, eentje lezen en eentje schrijven, en bij het 'kopieren' tussen de streams de bewerkingen uitvoeren.

[Verwijderd]

OK, sorry voor de onduidelijkheid. Het gaat om een editor. Huidige functies zijn onder andere

1. invoegen van null pakketten
2. verwijderen van pakketten
3. bewerken van pakketen (veranderen van PIDs, continuity counters, adaptation fields, payloads enzovoorts)
4. zoeken naar pakketten die voldoen aan gegeven criteria

[Onbekend]

Als je het niet volledig in het geheugen kunt laten, zul je dat in blokken moeten doen.
Bij scrollen sla je het gewijzigde blok (+ de index waarop de wijziging is uitgevoerd) tijdelijk op, en lees je met de file steam het nieuwe blok bij.
Bij het saven van het document, hoef je alleen die stream opnieuw door te gaan en de apart opgeslagen wijzigingen door te voeren.

[Verwijderd]

Dank je, nu lijken we ergens te komen Ik moet hier wat over na denken om te zien hoe dit verder aangevuld / verbeterd kan worden met verwijderde data en nieuw toegevoegde data.

[ACM]

[quote]Verwijderd schreef op zondag 09 juni 2013 @ 17:06:
OK, sorry voor de onduidelijkheid. Het gaat om een editor. Huidige functies zijn onder andere
• invoegen van null pakketten
• verwijderen van pakketten
Je bedoelt hiermee dus dat in potentie de gehele inhoud van de file 'verschoven' kan worden als iemand aan het begin een null-pakket toevoegt of een verwijdert?

Dan heb je wel een uitdaging te pakken... Althans, om dat efficient te doen. Als alle pakketten altijd evengroot zijn en altijd op de zelfde plek blijven, dan kan je veel makkelijker met een offset/window in je file de boel presenteren.

[q]• bewerken van pakketen (veranderen van PIDs, continuity counters, adaptation fields, payloads enzovoorts)
Kunnen de pakketten groter of kleiner (in bytelength) worden hierdoor? Zoja, zelfde uitdaging. Zonee, dan moet je vooral weten waar dat pakket stond om 'm later op die positie weer te kunnen overschrijven.

• zoeken naar pakketten die voldoen aan gegeven criteria

Hiervoor moet je waarschijnlijk dan de file lineair doorzoeken. Eventueel kan je dat multi-threaded doen door een tweede thread halverwege te laten beginnen.

Wat je ook kan bekijken is of het opportuun is om een zoek-index voor je bestand aan te leggen (bijv hashmaps voor criteria -> pakketposities) als die in het geheugen kleiner gehouden kan worden dan het bestand zelf.

[epic007]

Kijk ook eens naar memory mapped files:

http://en.wikipedia.org/wiki/Memory-mapped_file

http://msdn.microsoft.com/en-us/library/ms810613.aspx

[Dars123]

Geheugen bijprikken?

Wat zijn precies de redenen waarom dit niet in een database past?

[ Voor 63% gewijzigd door Dars123 op 10-06-2013 09:46 ]

[MSalters]

De methodes die serieuze editors gebruiken is vrij simpel. Je output file wordt in 1 keer geschreven, als kopie van de oude file. Vorodat de schrijfactie begint, wordt de filesize al gezet. Het OS alloceert dus in 1 keer de hele file, wat zorgt voor lage fragmentatie en dus hoge schrijfsnelheden.

Dat betekent natuurlijk dat je edit functionaliteit NIET schrijft. Je edit functionaliteit maakt alleen segmenten aan. Bijvoorbeeld segment 0 = 207 frames, startend bij input frame 24, segment 1 = 45 frames, segment 1 = 4032 frames, startend bij input frame 270 (impliciet geknipt: frames 0-23, 232-269).

Zelfs als je 1000 edits op een file van 1GB hebt, dan nog kun je toe met < 1MB ram voor zo'n lijst.

[Gomez12]

aanvulling @MSalters : Je edit functionaliteit schrijft wel, maar enkel naar allerlei temporary files, enkel een daadwerkelijk save-actie plakt de temporary files aan elkaar (op basis hiervan kan je bijv ook verdergaan als je editor crashed, zolang je temporary files bestaan en genoeg info bevatten kan je de vorige situatie opnieuw creeeren)