Divx / mpeg1 vcr in linux?

[iGadget]

Voor het vervangen van onze huidige VHS zendlijnregistratie wil ik een DivX of MPEG1 (als DivX niet haalbaar is) registratie doos bouwen onder linux. Wat is precies de bedoeling:

*Project A*
Deze doos moet 24/7/365 opnemen. Het aangeboden signaal is video over composiet, audio in stereo.

Het formaat waarin opgenomen dient te worden is het liefst DivX (vanwege de beperkte grootte) of, als DivX niet haalbaar is, MPEG1. De resolutie wordt waarschijnlijk half-pal, dus dat is 360x288? Het audio moet op 44kHz/16bit gesampled gaan worden. De compressie mag mp3 zijn, 128kbit of Ogg Vorbis of whatever, als het maar weer afspeelbaar is.

Dit zal misschien al een project op zich zijn, maar om het nog erger te maken moet er ook nog het volgende gebeuren:

*Project B*
-Elk uur moet er een nieuwe file aangemaakt worden, dus per dag zijn er 24 files.
-Deze filename moet iets worden in de trant van 'dagvandemaand_uur.mpg', dus de opname van 11 mei van 7:00 - 8:00 uur zou bijvoorbeeld 11_07.mpg moeten gaan heten.
-Als er een nieuwe maand begint mag de eerste file weer overschreven worden, dus in totaal komt er een maand aan video op de bak te staan.
-Via het netwerk moeten deze files dan vervolgens weer af te spelen zijn en overgezet kunnen worden op VHS (voor als het Commessariaat voor de Media een zendlijn wil zien). Ik wil dit in eerste instantie gewoon via samba oplossen, met een aparte machine voor de playout. Dit moet geen probleem zijn.

Deze machine gaat dus 24/7/365 video registreren, en moet daarom rocksolid zijn. Vandaar mijn voorkeur voor linux. In principe mag het gewoon een consoletool zijn die het inkomende signaal hard door de (software) encoder heen ramt naar de harddisk toe.

In hoeverre zijn Project A en B haalbaar met de huidige multimediale stand van zaken mbt Linux? Welke hardware / software zal ik voor Project A nodig hebben, en zou het moeilijk zijn om Project B te (laten) programmeren?

[visionz]

In principe is dit allemaal heel goed mogelijk. Echter als je een beetje kwaliteit video wilt overhouden zul je HEEL wat diskspace moeten hebben wil je een maand aan video willen kunnen opslaan.

[iGadget]

dat is geen probleem, ik heb 250 GB gebudgeteerd. Mocht dit ook niet voldoende zijn, dan is dit altijd nog uit te breiden. Het gaat mij meer om de overige hardware, welke kaarten worden ondersteund? Met welke programma's stuur ik deze het slimste aan? Welke opties voor encoden heb ik?

[Papillon]

Uitgaande van een stream van 900 kbit/s zul je in geval van DivX tenminste 280 GB(yte) nodig hebben. Reken maar na:

(900000/8) = 112500 bytes/s

112500 * 60(sec) * 60(min) * 24(uur) * 31(dagen) =3.0132 x 10^11 (= ca. 281 GB)

In het geval van MPEG1 met bijv VCD kwaliteit (= 1150 kbit/s) heb je al ca. 359 GB nodig. (hierbij is de OS buiten beschouwing gelaten en werken we niet met VBR)

Ik weet niet hoe je dit wil afhandelen, maar volgens mij is een PIII niet snel genoeg om DivX zo snel te encoden. Er is heel misschien al wel een kaart op de markt die het hardwarematig afhandelt. Waarschijnlijk is VCD (MPEG1 met 1150 kbit/s) een betere optie voor je. Hoogstwaarschijnlijk trekt een PIII dat wel. In elk geval zijn daarvoor zeker kaarten op de markt die het signaal hardware matig encoden. Let hierbij wel op de compatibility met Linux.

Hopelijk helpt dit je wel enigzins op weg.

[Verwijderd]

Op zaterdag 11 mei 2002 05:44 schreef iGadget het volgende:
Het formaat waarin opgenomen dient te worden is het liefst DivX (vanwege de beperkte grootte) of, als DivX niet haalbaar is, MPEG1. De resolutie wordt waarschijnlijk half-pal, dus dat is 360x288? Het audio moet op 44kHz/16bit gesampled gaan worden. De compressie mag mp3 zijn, 128kbit of Ogg Vorbis of whatever, als het maar weer afspeelbaar is.

Moet te doen zijn...

mp1e (meegeleverd met zapping) is een MPEG recording tool. NVrec (http://www.ee.up.ac.za/~justin/v4l2/) kan ook divx/mpeg recorden.

-Elk uur moet er een nieuwe file aangemaakt worden, dus per dag zijn er 24 files.
-Deze filename moet iets worden in de trant van 'dagvandemaand_uur.mpg', dus de opname van 11 mei van 7:00 - 8:00 uur zou bijvoorbeeld 11_07.mpg moeten gaan heten.
-Als er een nieuwe maand begint mag de eerste file weer overschreven worden, dus in totaal komt er een maand aan video op de bak te staan.

Als je nou gewoon via een scriptje de recorder voor 1 uur laat runnen. . Na dat uur reset je de recorder gewoon - en ga je dus door met recorden richting een nieuwe file.

Het resetten zal iets van enkele tienden van seconden kosten, het voordeel is dat je dan dus dat filenaam van jou handmatig kan regelen. Bovendien kun je eventuele A/V sync issues (ik ben nooit overtuigd geweest van de A/V sync van mp1e/NVrec) hiermee beperken tot de effecten van een uur. .

-Via het netwerk moeten deze files dan vervolgens weer af te spelen zijn en overgezet kunnen worden op VHS (voor als het Commessariaat voor de Media een zendlijn wil zien). Ik wil dit in eerste instantie gewoon via samba oplossen, met een aparte machine voor de playout. Dit moet geen probleem zijn.

Moet met samba te doen zijn. Let wel, de load van die bak zal omhoog gaan door de netwerk load - dit kan negatieve effecten hebben op de capture die op dat moment bezig is.

In hoeverre zijn Project A en B haalbaar met de huidige multimediale stand van zaken mbt Linux? Welke hardware / software zal ik voor Project A nodig hebben, en zou het moeilijk zijn om Project B te (laten) programmeren?

Hardware: simpel BTTV TV kaartje. Software: NVrec/mp1e... Moet te doen zijn, mits je die enkele tienden van seconden verlies voor lief neemt. .

[Verwijderd]

't is misschien een stom antwoord, maar wat denken jullie van een 64-bit SPARC om dat encoden af te handelen? Dat zal toch stukken sneller gaan dat met een Pentium 3/4?
Met DivX 5 Pro is de encoding misschien realtime, voor zover die dat ondersteunen

Anders is er nog altijd 3ivX. Voor Windows redelijk duur, maar voor Linux, Solaris, BeOS zijn ze gratis of goedkoop (www.3ivx.com). De makers beweren trouwens dat 3ivx kwaliteit beter is dan DivX.

[Martin Sturm]

Een tijd terug heeft er een stuk in de C'T gestaan over iets dergelijks. Conclusie was wel dat als je echt realtime wil encoden, je een zeer vet systeem nodig hebt, maar dat het met de huidige hardware goed mogelijk is.

BTW waarom samba? als je afspeelmachine ook Linux/Unix draait, kun je imho beter NFS gebruiken.. samba is alleen maar noodzakelijk kwaad om windows icm Linux te kunnen gebruiken.

[RG]

Wat je dan in ieder geval moet doen is een kernel installeren met een super lage latency (pre-emptible kernel patch of low latency patch) en een dikke proc hebben. Mpeg2 kan geloof ik door snelle Pentium3's al realtime gedaan worden. DivX zal heel wat moeilijker gaan denk ik zo, misschien met de snelste Pentium4 of Athlon.

Je moet gewoon een top systeem hebben daarvoor, da is duidelijk. Ik zou SCSI RAID 5 nemen want dat heb je wel nodig voor de opslag bijvoorbeeld voor de betrouwbaarheid. IDE RAID of LVM zou ik niet aan beginnen als je echt stabiel wilt zijn...

Onder Linux bestaan al best aardig wat van die Video Recordes. De TiVo is een hardwarematig ding dat in mpeg2 opneemt meen ik (wordt alleen in de VS verkocht). Dus hetmoet allemaal goed mogelijk zijn, alleen misschien moet je zelf een beetje aan het coden/scripten.

[TD-er]

Je zou ook wat kunnen besparen op de CPU-power en er een duurdere capture kaart in kunnen zetten, zoals de Hauppauge PVR.
Die comprimeert zelf al naar Mpeg 1 of 2.
Dan heb je minder problemen, wanneer de HDD via Samba aangesproken gaat worden.
en met de berekening hierboven, waarin gezegd werd dat Mpeg1 1150 kbit was.. dat is alleen de video
De standaard van Mpeg1 schrijft toch voor dat het evenveel data inneemt als de data op een audio CD (dus 80 min CD past ook ongeveer 80 mins aan Mpeg1 op)
oftewel 176,4 kB (of 172,3 KiB ) (= 14,2 GiB / dag)
dus voor een maand zul je toch in de orde van 450 GB nodig hebben, wil je Mpeg1 gebruiken.

[easydisk]

VCR-HOWTO - Using your GNU/Linux computer as a VCR
http://www.geocities.com/slothmud/

Voor uurtje divx3 ben je 600 a 700 MB kwijt, maar je kan tuurlijk ook divx4 nemen, zit je wat lager. (per dag dus max 17 GB.

Zelf doe ik realtime divx3 en 4 op een AMD 900 en dan kan ik nog andere dingen doen ook (het gebruikt ca 60 a 75% cpu) dus als je samba etc ook wilt moet je dat wel hebben.

[Verwijderd]

Op zaterdag 11 mei 2002 12:57 schreef TD-er het volgende:
Je zou ook wat kunnen besparen op de CPU-power en er een duurdere capture kaart in kunnen zetten, zoals de Hauppauge PVR.

De MPEG encoding van deze chip wordt (afaik) niet ondersteund onder linux. Je kan deze kaart (met wat handwerk) slechts als TV kaart gebruiken momenteel...

[iGadget]

Whow... tof man, al die reacties

Ik weet dat onder windoos je al realtime DivX kan encoden met een Athlon 1400. Dus met een Athlon XP 2000+ machine moet dit geen enkel probleem zijn, zeker als je de grafische schil er niet omheen hebt van windoze... of denk ik nu te simpel?

MPEG1 valt wat mij betreft af, want bijna 500GB voor alleen de zendlijnen vind ik wat teveel van het goede. Hoeveel neemt DivX op half Pal? Dus res 360x288, bitrate ?, audio mp3 / ogg vorbis, 128kbit of nog iets lager.
De videobitrate zal testen worden, wat nog acceptabel is, zolang het er ongeveer zo goed uit ziet als mpeg1 is het wat mij betreft prima (VHS kwaliteit dus).

Als je nou gewoon via een scriptje de recorder voor 1 uur laat runnen. . Na dat uur reset je de recorder gewoon - en ga je dus door met recorden richting een nieuwe file.
Het resetten zal iets van enkele tienden van seconden kosten, het voordeel is dat je dan dus dat filenaam van jou handmatig kan regelen. Bovendien kun je eventuele A/V sync issues (ik ben nooit overtuigd geweest van de A/V sync van mp1e/NVrec) hiermee beperken tot de effecten van een uur.

Kijk dat klinkt al goed... zoiets lijkt me prima, simpel, straight on, geen gezeik.

Moet met samba te doen zijn. Let wel, de load van die bak zal omhoog gaan door de netwerk load - dit kan negatieve effecten hebben op de capture die op dat moment bezig is.

Ik zit er over te denken om de opslag via een netwerkshare te doen, dus dat de encoder machine zelf zich daar geen zorgen over hoeft te maken (moet de netwerkkaart dus geen el-cheapo ding zijn, maar dat mag duidelijk zijn). Bijkomend voordeel is dus dan dat mocht er vanaf die losse storagebak files getrokken gaan worden, dat dat niet ten koste gaat van de cpu load van de encoder machine. Als die storagebak ook linux draait is NFS inderdaad mogelijk, alleen heb ik hier nog geen ervaring mee. Ontbrak in NFS niet de CRC? Corrupte files zit ik niet op te wachten natuurlijk...

Wat je dan in ieder geval moet doen is een kernel installeren met een super lage latency (pre-emptible kernel patch of low latency patch) en een dikke proc hebben. Mpeg2 kan geloof ik door snelle Pentium3's al realtime gedaan worden. DivX zal heel wat moeilijker gaan denk ik zo, misschien met de snelste Pentium4 of Athlon.

Whow... dat klinkt goed, van die latency kernel... is hier een HOWTO voor?
MPEG2 is geen optie, dat zou teveel ruimte in gaan nemen. 1,5mbit MPEG1 is al too much data...
DivX heb ik (onder windoze welliswaar) al realtime zien encoden op een Athlon 1400. Dus met een flinke XP erin zou dit geen probleem moeten zijn toch?

Je moet gewoon een top systeem hebben daarvoor, da is duidelijk. Ik zou SCSI RAID 5 nemen want dat heb je wel nodig voor de opslag bijvoorbeeld voor de betrouwbaarheid. IDE RAID of LVM zou ik niet aan beginnen als je echt stabiel wilt zijn...

Nah volgens mij is SCSI een beetje over the top... Ik zit zelf te denken aan zo'n onwijs geile ProCase kast met 8 of 16 van die hot-swappable IDE trays. Dit dan weer aangesloten op 1 of 2 3Ware Escalade 7810 kaarten in RAID5 modus. Maar dit is een apart project waar ik nog veel meer dingen mee wil gaan doen

Je zou ook wat kunnen besparen op de CPU-power en er een duurdere capture kaart in kunnen zetten, zoals de Hauppauge PVR.
Die comprimeert zelf al naar Mpeg 1 of 2.

MPEG1 / 2 is zoals gezegd geen optie meer vanwege de too much data... En ik denk niet dat die kaarten DivX snappen.

VCR-HOWTO - Using your GNU/Linux computer as a VCR
http://www.geocities.com/slothmud/
Voor uurtje divx3 ben je 600 a 700 MB kwijt, maar je kan tuurlijk ook divx4 nemen, zit je wat lager. (per dag dus max 17 GB.
Zelf doe ik realtime divx3 en 4 op een AMD 900 en dan kan ik nog andere dingen doen ook (het gebruikt ca 60 a 75% cpu) dus als je samba etc ook wilt moet je dat wel hebben.

Kiiijjjk... now we're talkin'!
Ik ga die site es even goed doorlezen... Thanks!

[RG]

Op zaterdag 11 mei 2002 14:16 schreef iGadget het volgende:
Whow... dat klinkt goed, van die latency kernel... is hier een HOWTO voor?
MPEG2 is geen optie, dat zou teveel ruimte in gaan nemen. 1,5mbit MPEG1 is al too much data...
DivX heb ik (onder windoze welliswaar) al realtime zien encoden op een Athlon 1400. Dus met een flinke XP erin zou dit geen probleem moeten zijn toch?

Ow dat valt mee, dan zal dat in Linux met een goede encoder ook geen probleem zijn. Dat van die kernel zal ik wel f uitzoeken. Een van de hoofdpunten om die pre-emptible kernel te maken had met het opnemen van video te maken. Ik zal het ff gaan uitzoeken, maar ik denk als je bak maar voor 70% belast wordt ofzo, dat niet per se noodzakelijk is, maar ik zoek het ff uit...

[RG]

Why Reduce Scheduler Latency?
Having a large scheduler latency means that the kernel doesn't respond very quickly to I/O events. If you're building a Personal Digital Recorder (PDR), then you are going to be processing the heck out of MPEG audio/video streams and you will want the kernel to schedule your MPEG decoder process as quickly as possible. If somebody misses the juicy bits from their favorite B-movie because the video stream glitched, they're not going to care that it's because the kernel was slowed down by a particularly slow write to the internal disk. They're just gonna be mad that the movie looks jerky.

Maar ik wet niet of dat nu ook van toepassing is als je het over het netwerk gaat opslaan, dat kan je het beste zelf tetsen met en zonder de patch.

[TD-er]

Op zaterdag 11 mei 2002 20:13 schreef RG© het volgende:

[..]

Maar ik wet niet of dat nu ook van toepassing is als je het over het netwerk gaat opslaan, dat kan je het beste zelf tetsen met en zonder de patch.

Netwerk I/O is ook I/O, dus zul je ook hier minder gauw last krijgen dat 'ie z'n buffers vol heeft zitten.
Als het ding maar één taak staat uit te voeren (capturen en comprimeren) dan heeft die preemptive kernel volgens mij wel zin.
Aan de andere kant is een I/O glitch (naar hdd/netwerk) niet echt een probleem, want er is niet zo heel veel data op te slaan per seconde. De topicstarter vind (terecht) 170 kB/s te veel