Sådan fungerer SeaMeet (Teknisk)
Kapitel 24: Sådan fungerer SeaMeet (Teknisk)
Introduktion
Har du nogensinde undret dig over, hvad der sker bag kulisserne, når du trykker på knappen "Optag"? Hvordan kaicp SeaMeet din skærm, koder video, gemmer filer og gør det alt i realtid uden at forvandle din computer til en brødrister? Dette kapitel trækker gardinet til side og forklarer den tekniske magi, der får SeaMeet til at fungere.
Du behøver ikke en kandidatgrad i datalogi for at forstå dette. Vi forklarer alt på almindeligt sprog ved hjælp af analogier og visuelle eksempler. Når du er færdig, vil du have en solid forståelse af optagelsesrørledningen, fra det øjeblik du klikker på "Optag", til filen vises i dit bibliotek.
Kapitelmål
Efter at have læst dette kapitel vil du kunne:
- Forstå den komplette optagelsesrørledning fra start til slut
- Vide, hvordan lyd- og videokaicp fungerer på et teknisk niveau
- Forstå kodning, komprimering og filformater
- Lære, hvordan Flashbacks cirkulære buffer fungerer
- Vide, hvordan Auto-Detektion overvåger dit system
- Forstå, hvorfor visse tekniske begrænsninger eksisterer
- Træffe informerede beslutninger om indstillinger baseret på teknisk viden
Del 1: Oversigt over optagelsesrørledningen
En optagelses rejse
Lad os spore, hvad der sker, når du klikker på "Start optagelse":
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ KAICP │ → │ BEHANDLING │ → │ KODNING │ → │ GEM │
│ │ │ │ │ │ │ │
│ Skærm + │ │ Rådata │ │ Komprimer │ │ Skriv til │
│ Lyd │ │ bufring │ │ video/lyd │ │ disk │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
↓ ↓ ↓ ↓
30-60 fps Hukommelsesbuffere H.264/MP3 MP4/WebM
44.1-48kHz Midlertidig Komprimering Endelig fil
Tidsskala: Alt dette sker løbende, 30-60 gange pr. sekund, mens du optager.
Del 2: Videokaicp
Sådan fungerer skærmkaicp
Konceptet: Din computerskærm er som et konstant skiftende maleri. SeaMeet tager fotografier af dette maleri, meget hurtigt, for at skabe en video.
Teknisk proces:
-
Billede-grab
Operativsystemet leverer: ┌─────────────────────────────┐ │ Skærmbuffer (billede) │ │ 1920×1080 pixels │ │ 60 gange pr. sekund │ └─────────────────────────────┘ ↓ SeaMeet kaicp denne buffer -
Billedbuffer
Det kaipturede billede går til: ┌─────────────────────────────┐ │ RAM-buffer │ │ Midlertidigt opbevaringsområde │ │ Kø til kodning │ └─────────────────────────────┘
Tre kaicp-tilstande:
Fuldskærmskaicp:
Kaicp hele skærmbufferen
Størrelse: 1920×1080 × 4 bytes pr. pixel = ~8 MB pr. billede
Ved 30 fps: 240 MB pr. sekund rådata
Vinduekaipcp:
OS fortæller SeaMeet: "Vinduet er ved koordinater (x, y, bredde, højde)"
SeaMeet kaicp kun dette rektangel
Mindre størrelse = færre data
Regionskaicp:
Du definerer rektangel: (start_x, start_y, bredde, højde)
SeaMeet kaicp præcis dette område
Mest effektiv (mindst data)
Billedhastighed-matematikken
Hvad 30fps egentlig betyder:
30 billeder pr. sekund =
• 30 skærmkaicp pr. sekund
• 1 billede hvert 33,3 millisekunder
• 1.800 billeder pr. minut
• 108.000 billeder pr. time (30fps)
Ved 1080p opløsning:
• 1 billede = 1920 × 1080 pixels
• 1 billede = 2.073.600 pixels
• 1 billede = ~6 MB ukomprimeret
• 30 billeder = ~180 MB pr. sekund ukomprimeret
• 1 time = ~650 GB ukomprimeret!
Det er derfor komprimering er afgørende!
Del 3: Lydkaicp
Sådan fungerer lydoptagelse
Konceptet: Lyd er bølger. Din computer konverterer disse bølger til tal, meget hurtigt.
Teknisk proces:
-
Mikrofon-input
Lydbølger → Mikrofon → Analogt signal ↓ Analog → Digital Konverter (ADC) -
Sampling
Sample-rate: 44.100 eller 48.000 samples pr. sekund Tænk på det som at tage et foto af en bølge: • 48.000 fotos pr. sekund • Hvert foto kaicp bølgehøjden på det tidspunkt • Flere samples = mere nøjagtig bølgereproduktion -
Bitdybde
16-bit = 65.536 mulige værdier 24-bit = 16.777.216 mulige værdier Som pixels i et foto: • Flere bits = flere "farver" af lyd • Bedre dynamisk område (stille vs. høj)
Matematikken:
CD-kvalitetslyd:
• 44,1 kHz sample-rate
• 16-bit dybde
• 2 kanaler (stereo)
• Pr. sekund: 44.100 × 16 × 2 = 1.411.200 bits = 176 KB/s
• Pr. minut: ~10,5 MB ukomprimeret
Høj kvalitetslyd:
• 48 kHz sample-rate
• 24-bit dybde
• 2 kanaler
• Pr. sekund: 48.000 × 24 × 2 = 2.304.000 bits = 288 KB/s
• Pr. minut: ~17 MB ukomprimeret
Systemlydkaicp
Sådan fungerer det:
Systemlyd "kaicp" ikke fra højttalerne — den opfanges inden den når højttalerne:
Applikation → Systemlydmixer → Højttalere
↓
SeaMeet
↓
Optagelse
På Windows:
- Bruger "Stereo Mix" eller loopback-optagelse
- Opfanger lydstream på drivniveau
- Ingen kvalitetstab
På macOS:
- Kræver skærmoptagelsestilladelse
- Bruger CoreAudio-framework
- Opretter virtuel lydenhed
Del 4: Kodning og Komprimering
Hvorfor vi har brug for Komprimering
Problemet:
Rå 1080p 30fps video:
• 180 MB pr. sekund
• 10,8 GB pr. minut
• 650 GB pr. time!
Rå CD-lyd:
• 10,5 MB pr. minut
• 630 MB pr. time
Ingen computer kan skrive så meget data så hurtigt!
Løsningen: Komprimering
Videokomprimering (Codecs)
Sådan fungerer videokomprimering:
Billedtyper:
I-Billede (Keyframe): Komplet billede
• Som et fuldt fotografi
• Stor filstørrelse
• Referencepunkt
P-Billede (Forudsagt): Ændringer fra forrige billede
• Gemmer kun det, der ændrede sig
• Meget mindre
• "Personens mund bevægede sig"
B-Billede (Tovejs): Ændringer fra fortid og fremtid
• Mest effektiv
• Referencer billeder før og efter
• Kompleks at kode
Eksempel:
Videosekvens: I P P B P B P I P P B P
I-Billede: Fuldt billede (stort)
P-Billede: Kun bevægelige dele (lille)
B-Billede: Smart forudsigelse (mindst)
H.264 komprimeringsproces:
- Opdel billede i macroblocks (16×16 pixel-firkanter)
- Sammenlign med forrige billede
- Find matchende blokke
- Gem kun forskelle
- Anvend matematiske transformationer (DCT)
- Kvantisering (reducer præcision)
- Entropikodning (effektiv bit-pakning)
Komprimeringsforhold:
Ukomprimeret: 650 GB pr. time
H.264 komprimeret: 4-8 GB pr. time
Komprimeringsforhold: ~100:1
Videoen ser næsten identisk ud!
Kvalitetstabet er næppe mærkbart.
Lydkomprimering
Tabsfri vs. Tabsgivende:
Tabsfri (WAV, FLAC):
- Bevarer hver bit lyd
- Som en ZIP-fil til lyd
- 50% størrelseseduktion
- Perfekt kvalitet
Tabsgivende (MP3, AAC):
- Fjerner "uhørlige" lyde
- Meget mindre filer
- 90% størrelseseduktion
- Kvalitetstab (men ofte umærkeligt)
MP3 komprimeringsproces:
-
Psykoakustisk model
- Identificerer lyde, mennesker ikke kan høre
- Fjerner dem
-
Frekvensanalyse
- Opdeler lyd i frekvensbånd
- Komprimerer hvert bånd forskelligt
-
Bit-allokering
- Flere bits til hørbare lyde
- Færre bits til maskerede lyde
-
Huffman-kodning
- Effektiv bit-pakning
Komprimeringsforhold:
Ukomprimeret WAV: 630 MB pr. time
MP3 128 kbps: ~60 MB pr. time (90% mindre)
MP3 320 kbps: ~150 MB pr. time (75% mindre)
Del 5: Flashback-systemet
Cirkulær Buffer-arkitektur
Konceptet: Forestil dig et transportbånd, der løber i ring. Genstande forbliver på båndet i en fast tid, derefter falder de af enden.
Teknisk implementering:
Flashback Buffer-struktur:
┌──────────────────────────────────────────────────────────┐
│ Cirkulær Buffer (RAM) │
│ │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │B1 │→│B2 │→│B3 │→│B4 │→│B5 │→│B6 │→│B7 │ │
│ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ │
│ ↑ ↓ │
│ └─────────────────────────────────────────┘ │
│ (løber i ring) │
│ │
│ Hvert "B" = 1 sekund video │
│ Bufferstørrelse: 60 sekunder = 60 billeder gemt │
└──────────────────────────────────────────────────────────┘
Skriveproces (løbende):
1. Skriv billede til nuværende position
2. Flyt til næste position
3. Hvis ved enden, gå tilbage til start (overskriv)
4. Gentag 30-60 gange pr. sekund
Gemmeproces (ved udløser):
1. Marker nuværende position som "slut"
2. Læs baglæns for buffervareighed
3. Kopier alle markerede billeder
4. Kode til endelig videofil
5. Bufferen fortsætter uafbrudt
Hukommelsesstyring:
Bufferstørrelse beregning:
For 60-sekunders buffer ved 1080p 30fps:
• Rå: 180 MB/s × 60s = 10,8 GB (alt for meget!)
• Komprimeret i buffer: ~3 MB/s × 60s = 180 MB
• Faktisk forbrug med overhead: ~200-250 MB
Hvorfor dette virker:
- Hukommelse er hurtig (RAM kan håndtere det)
- Løbende overskrivning = konstant hukommelsesforbrug
- Øjeblikkelig gem = bare kopier buffer til disk
- Ingen ydeevnepåvirkning, når bufferen er fuld
Del 6: Auto-Detektionssystem
Sådan fungerer detektion
Overvågningsløkken:
Hvert 500 millisekunder (2 gange pr. sekund):
1. TJEK VINDUETITLER
├─ Hent liste over alle åbne vinduer
├─ Tjek hver titel for søgeord:
│ • "Zoom Meeting"
│ • "Microsoft Teams"
│ • "Google Meet"
│ • osv.
└─ Point: Match fundet = +50 point
2. TJEK KØRENDE PROCESSER
├─ Hent liste over aktive processer
├─ Tjek for:
│ • zoom.exe
│ • Teams.exe
│ • chrome.exe (med møde-URL)
└─ Point: Proces fundet = +30 point
3. TJEK LYDSTREAMS
├─ Overvåg aktive lydkanaler
├─ Detekter:
│ • Mikrofon aktiv?
│ • Højttaler aktiv?
│ • Begge sammen? (sandsynligvis møde)
└─ Point: Mødemønster = +40 point
4. TJEK VINDUESGEOMETRI
├─ Analyser vinduesformer
├─ Se efter:
│ • Fuldskærmsvideo
│ • Gallerivisningslayouts
│ • Mødekontrolfelt
└─ Point: Match = +20 point
5. EVALUER POINT
├─ Samlet point = sum af alle signaler
├─ Tærskel for detektion: 80 point
├─ Høj tillid: 120+ point
└─ Udløs handling baseret på point
6. VENT 500ms
└─ Gentag
Hvorfor denne tilgang:
- Flere signaler = nøjagtighed
- Vægtet pointtælling = fleksibilitet
- Hurtig løkke (2×/sek) = responsiv
- Lavt ressourceforbrug = effektiv
Del 7: Filformater og containere
Hvad er en container?
Analogi: En container er som en kasse, der indeholder forskellige elementer:
- Videospor (de bevægelige billeder)
- Lydspor(s) (lyden)
- Metadata (info om videoen)
- Undertekster (hvis nogen)
Container vs. Codec:
Container = Kassen (MP4, WebM, AVI)
Codec = Komprimeringsmetoden (H.264, VP8)
Tænk på det som:
Container = Mappemappe
Codec = Hvordan dokumenter er skrevet indeni
MP4 containerstruktur
MP4 filstruktur:
┌──────────────────────────────────────┐
│ ftyp (Filtype) │
│ "Dette er en MP4-fil" │
├──────────────────────────────────────┤
│ moov (Film-header) │
│ - Varighed: 3600 sekunder │
│ - Spor: 2 (video + lyd) │
│ - Tidsskalainfo │
├──────────────────────────────────────┤
│ mdat (Mediedata) │
│ ┌────────────────────────────────┐ │
│ │ Videospor (H.264) │ │
│ │ Billede 1, Billede 2, Billede 3│ │
│ └────────────────────────────────┘ │
│ ┌────────────────────────────────┐ │
│ │ Lydspor (AAC) │ │
│ │ Sample 1, Sample 2, Sample 3...│ │
│ └────────────────────────────────┘ │
└──────────────────────────────────────┘
Hvorfor MP4 er populær:
- Universel kompatibilitet
- Effektiv streaming
- Understøtter mange codecs
- God metadataunderstøttelse
- Virker på alle enheder
Del 8: Hardwareacceleration
CPU vs. GPU-kodning
CPU-kodning (Software):
Fordele:
• Højeste kvalitet
• Mest kompatibel
• Virker på alle computere
Ulemper:
• Meget langsom/CPU-krævende
• Tømmer batteri
• Kan forårsage systemsænkning
GPU-kodning (Hardware):
Fordele:
• Meget hurtig
• Lavt CPU-forbrug
• Dedikeret hardware
• Batterieffektiv
Ulemper:
• Lidt lavere kvalitet (næppe mærkbart)
• Kræver kompatibelt GPU
• Mindre fleksible indstillinger
Sådan fungerer hardwareacceleration
NVIDIA NVENC:
Proces:
1. Rå videobillede sendes til GPU
2. GPU's encoderchip behandler det
3. Specialiseret hardware udfører H.264-kodning
4. Kodet data sendes tilbage
5. CPU er næppe involveret
Resultat: 10-20% CPU-forbrug i stedet for 50-70%
Intel Quick Sync:
Indbygget i Intel-processorer
Dedikeret mediekodningshardware
Meget effektiv til bærbare computere
Lavt energiforbrug
AMD VCE:
Ligner NVENC men til AMD GPU'er
Hardware-kodningsblok på grafikkortet
God kvalitet, hurtig kodning
Del 9: Løbende diskskrivning — Nul datatab
Arkitekturen
SeaMeets optagelsesmotor er bygget omkring en streaming-til-disk-model. Video- og lyddata skylles løbende ud til outputfilen, mens optagelse foregår, frem for at holdes i hukommelsen, indtil brugeren stopper.
Traditionel optager:
┌──────────────────────────────────────────────────────────┐
│ RAM-buffer (vokser under optagelse) │
│ Billede 1 → Billede 2 → ... → Billede 216.000 (2 t @ 30fps) │
│ ↓ │
│ [Stop klikket] │
│ ↓ │
│ Skriv til disk │
│ (enkelt stor skylning) │
└──────────────────────────────────────────────────────────┘
SeaMeet streaming-model:
┌──────────────────────────────────────────────────────────┐
│ Billede 1-90 → kod → skriv chunk → disk ✅ │
│ Billede 91-180 → kod → skriv chunk → disk ✅ │
│ Billede 181-270→ kod → skriv chunk → disk ✅ │
│ ... │
│ [Stop klikket] → afslut container → færdig ✅ │
└──────────────────────────────────────────────────────────┘
Nøgleforskel: I SeaMeet eksisterer optagelsesfilen og vokser på disken fra de allerførste sekunder. Hvis optagelsen afbrydes på et hvilket som helst tidspunkt, kan alle chunks, der allerede er skyllet til disk, gendannes.
Teknisk implementering
Video (WebM/MP4 container streaming):
VideoRecordingEngine skriver kodede pakker direkte til
et åbent filhåndtag i streaming-tilstand:
KodetPakke → mux ind i container → flush() til OS-filcache
↓
fsync ved chunk-grænser
↓
Data forpligtet til disk
Lyd:
PCM samples → kod (MP3/AAC/WebM Opus) → skriv til filhåndtag
↓
Periodisk flush + sync
Chunk-grænser:
- Video: skylles hvert par sekunder ved keyframe-intervaller
- Lyd: skylles løbende med lydpakker
- Begge: OS-niveau
fsyncsikrer, at data overlever procesdød
Hvorfor det er vigtigt
Nedbrudssikkerhedstabel:
| Hændelse | Hukommelse-kun optager | SeaMeet |
|---|---|---|
| App-nedbrud | 100% datatab | Højst få sekunder tabt (sidste uskyllet chunk) |
| OS-nedbrud / BSOD / kernelpanik | 100% datatab | Alle skylt chunks overlever |
| Strømsvigt | 100% datatab | Alle skylt chunks overlever |
| Tvungen drab (kill -9) | 100% datatab | Alle skylt chunks overlever |
| Ordentligt stop | Fuld fil gemt | Fuld fil gemt |
Hukommelsesfodaftryk:
Traditionel: RAM-forbrug vokser med optagelsesvarighed
1 time 1080p @ 30fps ≈ 3,6 GB i RAM
SeaMeet streaming: RAM-forbrug forbliver konstant
1 time 1080p @ 30fps ≈ ~50-100 MB i RAM (kun encode-buffere)
→ Resterende 3,5+ GB allerede på disk
Dette betyder også, at SeaMeet kan håndtere vilkårligt lange optagelser uden at løbe ind i hukommelsesgrænser — en optagelse på flere timer bruger den samme spids-RAM som en på 5 minutter.
Del 10: Ydeevneoptimeringer
Hvorfor SeaMeet er effektiv
1. Streaming-skrivninger (ikke buffererede masseskrivninger):
I stedet for:
Billeder akkumuleres i RAM → [Stop] → Dump alt til disk
SeaMeet gør:
Billede → kod → skriv chunk til disk (hvert par sekunder)
Konstant, forudsigelig disk-I/O = ingen spids ved optagelsesslut
2. Asynkron kodning:
Kaicp-tråd: Henter billeder fra skærmen
Kodnings-tråd: Komprimerer billeder
Disk-tråd: Skriver til fil
Tre tråde arbejder parallelt
Ingen ventetid, maksimal effektivitet
3. Selektiv kvalitet:
Flashback bruger lavere kvalitet (hurtig kodning)
Regelmæssig optagelse bruger højere kvalitet
Brugeren kan vælge baseret på behov
4. Hukommelsesmapping:
Store filer mappet til hukommelse
OS håndterer paging effektivt
Hurtigere end traditionel fil-I/O
Del 10: Begrænsninger og restriktioner
Hvorfor nogle ting er umulige
1. Kan ikke optage DRM-indhold:
Netflix, Disney+ osv. bruger kryptering
Grafikkort dekrypterer til visning
Kan ikke kaicp dekrypteret stream
Juridisk/teknisk blok
SeaMeet kaicp skærmbufferen
Men DRM-indhold vises aldrig der
Resultat: Sort skærmoptagelse
2. Kan ikke kaicp beskyttede apps:
Nogle bank-apps blokerer skærmkaicp
OS-niveau sikkerhedsfunktion
Beskytter følsomme oplysninger
Kan ikke omgås (by design)
3. Lydforsinkelse med Bluetooth:
Bluetooth-lyd har indbygget forsinkelse
100-300ms typisk
Ikke SeaMeets skyld
Hardwarebegrænsning
Løsning: Brug kabelforbundne hovedtelefoner
4. Kan ikke optage i højere end skærmopløsning:
Skærm er 1080p → Maksimal optagelse 1080p
Kan ikke magisk oprette 4K fra 1080p
Pixeldata eksisterer ikke
Undtagelse: Nogle GPU'er understøtter opskalering
Men det er ikke ægte 4K
Sammenfatning
SeaMeet er et sofistikeret stykke ingeniørkunst, der:
✅ Kaicp skærm og lyd ved høj hastighed
✅ Komprimerer video/lyd i realtid (100:1 forhold!)
✅ Streamer løbende til disk — nul datatab selv ved nedbrud
✅ Bruger cirkulære buffere til Flashback tidsmaskine
✅ Overvåger flere signaler til auto-detektion
✅ Optimerer med hardwareacceleration og multi-threading
✅ Pakker alt ind i standard filformater
Vigtigste pointer:
- Løbende diskskrivning — Data er sikkert fra det første sekund; nedbrud mister højst få sekunder
- Komprimering er afgørende — Uden det ville filer være enorme
- Hardwareacceleration hjælper — Aflaster arbejde til GPU
- Flashback bruger RAM-buffer — Hurtig cirkulær lagring
- Auto-detektion er mønstergenkendelse — Flere signaler vægtet
- Codecs betyder noget — H.264 er universal, H.265 er effektiv
- DRM kan ikke optages — Teknisk og juridisk begrænsning
Tekniske termer forenklet:
- Codec = Komprimeringsmetode
- Container = Filformatboks
- Billede = Enkelt billede i video
- Sample = Øjebliksbillede af lydbølge
- Bitrate = Data pr. sekund
- Buffer = Midlertidig hukommelseslagring
- Latency = Forsinkelse mellem handling og optagelse
Kapitelcheckliste
Inden du går videre, bør du forstå:
- Hvordan skærmkaicp fungerer (billedgrabning)
- Hvorfor komprimering er nødvendig (filstørrelsesmatematik)
- Hvordan løbende diskskrivning beskytter dine optagelser
- Hvordan Flashbacks cirkulære buffer fungerer
- De fem auto-detektion-signaler
- Forskel på containere og codecs
- Hvad hardwareacceleration gør
- Hvorfor noget indhold ikke kan optages
Teknisk viden erhvervet! Du forstår nu magien bag SeaMeet.
Published: