Minimale systeemeisen AVCHD (afspelen en monteren)

[Anoniem: 22659]

In Film & Video worden vaak vragen gesteld mbt de systeemeisen voor een computer die AVCHD bestanden moet afspelen/monteren. Hier is echter niet een eenvoudig antwoord op te geven. Zaken als CPUs, GPUs, software en codecs lijken allemaal invloed te hebben op de weergave van AVCHD bestanden. Ik merk dat ik geen uitspraken durf te doen over de benodigde hardware, omdat ik het simpelweg niet weet. Ik weet alleen of de systemen waar ik mee werk AVCHD aankunnen of niet, maar kan dat moeilijk extrapoleren naar andere systemen.

Als oplossing had ik bedacht dat er op internet vast wel een of andere database moet zijn waarin de relevante specificaties zijn opgenomen waaruit je kunt opmaken of jouw (beoogde) systeem AVCHD aan kan of niet. Ik ben echter niet in staat om een dergelijke database of review te vinden. Dit zou een aanzienlijke bijdrage zijn aan de discussie omtrent AVCHD. Mijn belangrijkste vraag voor dit topic is dan ook of iemand een dergelijke link kan geven

Wanneer niemand in staat is om een dergelijke link te geven, dan is het misschien een idee om hier een sticky topic te openen waarin iedereen zijn relevante systeemspecs aandraagt en aangeeft of deze specs in staat zijn om AVCHD te bekijken/monteren. In dat geval zou ik graag willen weten welke systeemonderdelen relevant zijn voor mijn vraagstuk. Ik noem zelf even bewust geen componenten om de discussie niet gelijk te kaderen. Mijn concrete vragen zijn: welke componenten van een pc zijn van invloed op de weergave van AVCHD bestanden? Daarnaast direct de vraag of deze componenten alleen van invloed zijn op de weergave of ook op de montage?

Tot slot de vraag hoe we een dergelijk topic het beste kunnen aanpakken? Zou het afdoende zijn om iedereen zijn eigen bestand te laten beoordelen of moeten we zelf een bestand beschikbaar stellen en op basis daarvan de conclusies laten trekken? Moeten we dan ook aangeven met welke software moet worden gewerkt? Moeten we kiezen voor een stukje film met een gemiddelde bitrate (zeg bijvoorbeeld 17 mbit/s) of moeten we kiezen voor een stukje film met de maximale bitrate van 24 mbit/s?

Graag jullie antwoorden en visie op mijn vraagstuk

[dion_b]

Interessant vraagstuk.

Ik vrees dat er geen "makkelijk" antwoord op te geven is in de trant van "met minstens CPU x, GPU y en codec z werkt het altijd zeker" en "met minder dan CPU a, GPU b en codec c werkt het nooit", aangezien er zoveel variabelen zijn.

Het lijkt me dan ook zinniger om een paar zaken vast te leggen (bijv combinatie van OS, codec, schermresolutie en bronmateriaal) en dan daarvoor minimale eisen qua CPU+GPU of CPU alleen (bij GPU zonder acceleratie voor AVCHD, of voor gevallen waar een combo van codecs GPU acceleratie verhindert) te gaan zoeken.


Voorbeeld van wat ik bedoel:

• Windows 7 mediacenter + ATi Avivo + 1920x1080 (1080p) en max bitrate bromateriaal
• Linux + MythTV + default (OSS) codecs + 1920x1080 (1080p) en max bitrate bronmateriaal
• Moblin/Android/eeBuntu + CoreAVC codecs + 1280x800 (+-720p, voor netbooks) en max bitrate bronmateriaal

Per categorie zou je dan kunnen kijken wat minimaal nodig is. Klopt het trouwens dat 24Mbit/s de max bitrate is? Ik meen dingen gezien te hebben die qua bestandsomvang bijna de dubbele bitrate zouden doen vermoeden... sowieso denk ik dat je qua minimumspecs altijd max bitrate moet gebruiken. Je hebt verdraaid weinig aan een HTPC die alleen 1 op de 10 HD films kan decoden zonder problemen

[-DarkShadow-]

Het lijkt mij sowieso handig om een duidelijk verschil te maken tussen kijken en bewerken. Kijken gaat misschien prima op een laptop met AVCHD hardware decoder, maar bewerken kan dan nog steeds zeer traag gaan. Daarnaast zijn rendertijden ook interessant en die zijn het gemakkelijkst te benchen Maak een kort project aan in AE met weinig beeldmateriaal en veel layers. Nu kan iedereen precies hetzelfde project renderen en daar de tijd van opnemen. Goed initiatief trouwens!

[Anoniem: 22659]

Inmiddels even wat aliassen aangemaakt. Per direct wordt bevestigd dat ik hieraan goed heb gedaan, want ik benader dit vraagstuk vanuit een camcorder achtergrond en dion_b vanuit een HTPC achtergrond

Gelijk maar even een keihard bewijs van de ontegensprekelijke bron wikipedia aandragen:

quote: http://en.wikipedia.org/wiki/AVCHD#Specifications

up to 24 Mbit/s (AVCHD conforming to H264 High-Profile, Level 4.1)

Het enige dat ik kan bedenken waarom een bestand gevoelsmatig groter kan zijn dan de maximale bitrate zou vermoeden is dat er meerdere audiostreams inzitten of nog een hele zwik aan andere extra's.

Denk je overigens dat OS een grote invloed heeft op de wijze waarop een gebruiker AVCHD materiaal ervaart?

Tot slot nog even een andere overweging. De huidige range HD camcorders neemt op in een 1080i equivalent. Als er 1080p op zit dan gaat dat met de helft van de framerate van 1080i; ofwel het is of 1080i50 of 1080p25. Er zijn weinig camcorders die alleen in 720P schieten. Indien 24 mbit/s de maximale bitrate is van AVCHD dan maakt het imo dus niet uit of je gaat voor 1080P of 1080i. Een P frame kan maximaal het dubbele aan info bevatten met als gevolg dat de framerate omlaag dient te gaan 1080i of 1080p moet dus niet uitmaken; zolang het maar 24mbit/s is. Dan houdt je alleen nog de categorie laptop/netbook over!

[dion_b]

Anoniem: 22659 schreef op dinsdag 05 januari 2010 @ 14:42:
[...]

Gelijk maar even een keihard bewijs van de ontegensprekelijke bron wikipedia aandragen:

[...]


Het enige dat ik kan bedenken waarom een bestand gevoelsmatig groter kan zijn dan de maximale bitrate zou vermoeden is dat er meerdere audiostreams inzitten of nog een hele zwik aan andere extra's.

Duidelijk

Denk je overigens dat OS een grote invloed heeft op de wijze waarop een gebruiker AVCHD materiaal ervaart?

Absoluut, al is het alleen maar ivm overhead (hoeveel resources gebruikt OS zelf), driver support (verschillende drivers bieden dramatisch verschillende features aan), beschikbare codecs en zeker niet in de laatste plaats de beschikbare afspeel/bewerkingssoftware.

Daarnaast zijn er subtielere zaken die -zeker bij montage/encoding- mee kunnen spelen, zoals performance van het I/O subsysteem, efficientie van de SMP scheduler (hoe taken/threads over de beschikbare cores verdeeld worden) en zo nog meer van die dingen.

Tot slot nog even een andere overweging. De huidige range HD camcorders neemt op in een 1080i equivalent. Als er 1080p op zit dan gaat dat met de helft van de framerate van 1080i; ofwel het is of 1080i50 of 1080p25. Er zijn weinig camcorders die alleen in 720P schieten. Indien 24 mbit/s de maximale bitrate is van AVCHD dan maakt het imo dus niet uit of je gaat voor 1080P of 1080i. Een P frame kan maximaal het dubbele aan info bevatten met als gevolg dat de framerate omlaag dient te gaan 1080i of 1080p moet dus niet uitmaken; zolang het maar 24mbit/s is. Dan houdt je alleen nog de categorie laptop/netbook over!

Hmm, had nog niet stilgestaan bij interlaced modes. Qua bitrate zijn 1080i50 en 1080p25 natuurlijk uitwisselbaar, maar een interlaced mode zal bij afspelen (of bewerken) de CPU zwaarder belasten aangezien er dan gedeinterlaced moet worden. Of dit significant is tov overige belasting durf ik niet te zeggen, maar het is wel een verschil.

Even een vraag vanuit mijn camcorder-onwetendheid: wat is in deze tijd van TFT schermen die niet langer gekoppeld zijn aan de electrische frequentie van 50Hz de meerwaarde van 1080i50 boven 1080i60? En waarom wordt van 1080i60 1080p24 gemaakt ipv 1080p30?

[Anoniem: 22659]

dion_b schreef op dinsdag 05 januari 2010 @ 16:56:

Absoluut, al is het alleen maar ivm overhead (hoeveel resources gebruikt OS zelf), driver support (verschillende drivers bieden dramatisch verschillende features aan), beschikbare codecs en zeker niet in de laatste plaats de beschikbare afspeel/bewerkingssoftware.

Dit klinkt meer al de beschikbaarheid van de beschikbaarheid aan externe software dan aan beperkingen aan het OS

Daarnaast zijn er subtielere zaken die -zeker bij montage/encoding- mee kunnen spelen, zoals performance van het I/O subsysteem, efficientie van de SMP scheduler (hoe taken/threads over de beschikbare cores verdeeld worden) en zo nog meer van die dingen.

Denk je dat die verschillen dermate groot zijn dat ze dermate groot zijn dat ze het verschil tussen twee modellen processor vereisen (bijv).

Hmm, had nog niet stilgestaan bij interlaced modes. Qua bitrate zijn 1080i50 en 1080p25 natuurlijk uitwisselbaar, maar een interlaced mode zal bij afspelen (of bewerken) de CPU zwaarder belasten aangezien er dan gedeinterlaced moet worden. Of dit significant is tov overige belasting durf ik niet te zeggen, maar het is wel een verschil.

Ik vraag me even af of een computer standaard moet deinterlacen. Wat nu als je een VGA aansluiting en een CRT monitor gebruikt, moet je dan ook deinterlacen?

Even een vraag vanuit mijn camcorder-onwetendheid: wat is in deze tijd van TFT schermen die niet langer gekoppeld zijn aan de electrische frequentie van 50Hz de meerwaarde van 1080i50 boven 1080i60? En waarom wordt van 1080i60 1080p24 gemaakt ipv 1080p30?

Kortweg zou je kunnen stellen dat de EU modellen gebruik maken van 1080p25 en 1080i50 en dat de US modellen 1080i60, 1080p30 en 1080p24 gebruiken. Die 24p modus zit erop om een filmisch effect te creeeren. Ivm de overlap met 25P (of iig een dermate klein verschil) zit dat niet in de Europese modellen

[dion_b]

Anoniem: 22659 schreef op dinsdag 05 januari 2010 @ 17:11:
[...]

Dit klinkt meer al de beschikbaarheid van de beschikbaarheid aan externe software dan aan beperkingen aan het OS

Ook bij exact dezelfde software is het geenszins gegarandeerd dat OS+software identieke performance gaan leveren.

[...]

Denk je dat die verschillen dermate groot zijn dat ze dermate groot zijn dat ze het verschil tussen twee modellen processor vereisen (bijv).

Goede vraag, hangt ook af van de eisen (zie hieronder)

[...]

Ik vraag me even af of een computer standaard moet deinterlacen. Wat nu als je een VGA aansluiting en een CRT monitor gebruikt, moet je dan ook deinterlacen?

CRT monitoren (althans alle CRT monitoren van de afgelopen 15 jaar) tonen een progressive beeld - VGA is niets anders dan 480p. Analoog != interlaced. Alleen ouderwetse CRT TVs werken standaard in 576i interlaced mode.

Maareh, mbt eisen:

Voor het afspelen lijkt het me duidelijk: dat de hard/softwarecombo in staat is om vloeiend (zonder framedrops of sync problemen) het materiaal in realtime te tonen op de gewenste settings. Maar wat zie je als eis voor het bewerken? Dat hoeft nie per se real-time te gebeuren, dus in theorie kan dat op een 150MHz Pentium Pro, als je tenminste veel geduld hebt

Dus daar de vraag: wat is acceptabel?

[Anoniem: 22659]

dion_b schreef op dinsdag 05 januari 2010 @ 19:20:

Voor het afspelen lijkt het me duidelijk: dat de hard/softwarecombo in staat is om vloeiend (zonder framedrops of sync problemen) het materiaal in realtime te tonen op de gewenste settings. Maar wat zie je als eis voor het bewerken? Dat hoeft nie per se real-time te gebeuren, dus in theorie kan dat op een 150MHz Pentium Pro, als je tenminste veel geduld hebt

Tsja, goed punt. Ik denk dat het renderen zelf geen issue dient te zijn. Er zijn voldoende tests waaruit de verschillen tussen de processors mbt renderen zijn (tomshardware bijv). Hier kun je lijstjes vinden met standaard bewerkingen die zijn losgelaten op diverse processors. Hieruit kun je in ieder geval de verschillen in rendertijd bepalen. Wat acceptabel is, dat hangt af van budget en eisen.

Wat ik regelmatig hoor -en in beperkte mate ook heb meegemaakt- is dat het monteren van beelden niet vloeiend gaat. De computer speelt AVCHD bestanden wel af, maar tijdens de montage werkt de preview bijvoorbeeld niet vloeiend. Waarschijnlijk dat in dat geval de GPU niet bijdraagt Je criterium acceptabel wordt dan ingevuld met een vloeiende preview. Nadeel is dat dit denk ik enorm software afhankelijk is. In dat geval moeten we moet ik dus even op zoek naar een gratis montage programma voor AVCHD, zodat men het met dit programma kan testen.

Maar goed. Welke componenten denk jij dat in een lijstje moeten komen?

[dion_b]

Voor afspelen is het relatief simpel (aangezien I/O geen bottleneck gaat vormen), dat is puur CPU en GPU (RAM kun je evt bij stilstaan, maar aangezien zelfs een Netbook tegenwoordig met 2GB geleverd wordt, betwijfel ik of we daar veel aandacht aan hoeven te geven).

Monteren is een andere zaak. Mijn eigen kennis is beperkt, zelf doe ik er niets mee en ik heb maar één keer een systeem gebouwd voor een kennis die het ging doen. Dat was een Core i7 920 met 12GB RAM en dual Velociraptors in RAID-0 (en een paar 1TB schijven voor opslag) met Vista 64b en Adobe Premiere. Conclusie was iig dat zoveel RAM nergens voor nodig was bij Premiere onder Vista (totale RAM usage bleef onder de 6GB met net iets meer dan 4GB in gebruik door Premiere). GPU (HD4870 in dit geval) deed niets bij monteren, en het verschil tussen de Raptors en de reguliere 7200rpm schijven viel ook tegen (niet gek aangezien raptors vooral veel snellere access times hebben, maar geen noemenswaardig hogere throughput). Het leek dus met name HDD throughput-limited te zijn mbt inladen en puur CPU limited te zijn voor het renderen zelf - waarbij de i7 920 iig bevredigende resultaten gaf. Maarja, dat is ook een high-end monster

[kluyze]

Ik wil even op dat laatste stuk van dion_b ingaan. Aangezien mijn kennis ook niet heel hoog is ivm monteren ed. hoop ik geen al te grote flaters te maken. Maar ik wil toch mijn bevindingen delen, misschien dat het van enig nut kan zijn.

Ik heb zelf een i7 920 met 12GB aan ram en heb eens wat zitten testen met adobe premiere pro (cs4). Hoewel ik niet echt een montage had gemaakt ging het voornamelijk met mijn test om het omzetten van formaten. Al heb ik wel eens meerdere korte filmpjes samen gezet. De filmkes waren voornamelijk .mov bestanden van ongeveer 200-600MB als ik me niet vergis. En werden omgezet zowel in formaat (.mov -> .avi) als de grootte zelf (resolutie)

Ik had hiervoor een ramdisk (+/-5GBps) van 4GB gebruikt om te vergelijken met een reguliere data disk (WD green @5400rpm +/-90MBps) en ik moet zeggen het verschil was enorm. Ik had een aantal formaten getest (voornamelijk mov naar avi/divx) en als ik zowel het bron bestand als het resultaat op de ramdisk plaatste dan was de conversie stukken sneller gedaan als op de hdd.

Nu is het verschil in throughput tussen een hdd@5400rpm (<100MBps seq.) tov die ramdisk (+/-5GBps seq.) wel enorm. Maar mijn testen leken dus te wijzen dat er een grote bottleneck zat bij de hdd. Nu zoals gezegd is mijn kennis niet zo geweldig, zowel van adobe premiere als monteren in het algemeen en weet ik niet in hoeverre die test het besluit kan geven dat ik er uit haal.

[dion_b]

kluyze schreef op woensdag 06 januari 2010 @ 12:21:
[...]

Ik had hiervoor een ramdisk (+/-5GBps) van 4GB gebruikt om te vergelijken met een reguliere data disk (WD green @5400rpm +/-90MBps) en ik moet zeggen het verschil was enorm. Ik had een aantal formaten getest (voornamelijk mov naar avi/divx) en als ik zowel het bron bestand als het resultaat op de ramdisk plaatste dan was de conversie stukken sneller gedaan als op de hdd.

Nu is het verschil in troughput tussen een hdd@5400rpm (<100MBps seq.) tov die ramdisk (+/-5GBps seq.) wel enorm. Maar mijn testen leken dus te wijzen dat er een grote bottleneck zat bij de hdd. Nu zoals gezegd is mijn kennis niet zo geweldig, zowel van adobe premiere als monteren in het algemeen en weet ik niet in hoeverre die test het besluit kan geven dat ik er uit haal.

Dit bevestigt iig zeer duidelijk het belang van I/O doorvoer (en geeft me trouwens gelijk een tip uit een 100% vergelijkbare situatie (hard- en software) om aan die kennis met 12GB door te geven voor hoe hij die RAM wel degelijk nuttig kan inzetten )

Edit:
WTF? Vista heeft geen native ramdisk mogelijkheid? Dat kon onder DOS al ffs

Hoe heb jij die ramdisk aangemaakt?

[ Voor 5% gewijzigd door dion_b op 06-01-2010 13:35 ]

[kluyze]

http://www.superspeed.com/ramdisk.php Er zijn ook andere gratis tooltjes maar die kreeg ik onder vista x64 niet aan het draaien.

[ Voor 55% gewijzigd door kluyze op 06-01-2010 15:33 ]

[Cablekevin]

Ik blijf dit topic zeker volgen, ik moet ook een nieuwe computer aanschaffen, heb voor kerst een mooie AVCHD Sony camcorder gekregen, maar ik wil niet teveel uitgeven voor een nieuwe pc (premiere CS4 gebruiker). Hoop dat dat niet nodig is?

[Anoniem: 16225]

Interessante discussie, ik heb een hele berg AVCHD filmpjes nog niet gemonteerd omdat het op een X2 4400 gewoon niet loopt in ieder geval veel te langzaam. Mijn systeem is ook al weer >3 jaar dus dat moet eens een keertje vervangen worden. AVCHD weergave gaat wel goed met dit systeem (icm de CoreAVC codec) Dit jaar wil ik een AMD systeem samenstellen waarmee ik wel vlot kan monteren. Ik gebruik Sony Vegas Pro en daarmee worden in ieder geval de Cores volledig belast maar ook mijn HD's, dus ik denk dat een quad core of hopelijk een 6 voudige AMD core met SSD's wel uitkomst zal gaan bieden. Op mijn htpc systemen gebruik ik energiezuinige 4850e en 5050e en daarmee kan ik zonder problemen icm de CoreAVC codec AVCHD files mee afspelen dus op een moderne PC zou playback geen problemen moeten geven, montage is echter een ander verhaal.

[martin2005]

Interessante discussie. Helaas leidt dit meestal tot een diepgaande verhandelingen over PC hardware. Begrijpelijk, maar interesseert mij g... r..t. De PC is voor mij alleen een stuk gereedschap om te kunnen editten. Maar ik zal me helaas moeten verdiepen in de spullen onder de motorkap.

Wat ik in de populistische computerbladen lees, is dat de GPU alleen van invloed is op afspelen van AVCHD materiaal en dat bewerking (en dan vooral de vloeiendheid en snelheid ervan) bijna alleen afhankelijk is van processor (incl geheugen en interfacing naar de harde schijven).

Mijn eigen ervaringen bevestigen dit wel zo'n beetje. Ik krijg het met een beetje geduld prima voor elkaar mijn AVCHD materiaal (1080i, 17Mbps) te bewerken op mijn Sony Vaio VGN-FW11E met een C2D Mobile P8400, 3GB Ram. Dit met Adobe Premiere CS4 geïnstalleerd op Windows 7. Mede door W7 speelt het materiaal ook nog redelijk af. Ook de previews in Adobe gedurende de montage. Maar dat komt weer -denk ik- omdat Adobe gewoon low-res copies gebruikt en pas tijdens renderen de volle resolutie pakt.

Overigens zit er een HD3470 videokaart in de laptop, met UVD.... maar onder Vista helpt dat dus niks. Dus of UVD nu wel of niet helpt bij editten, is mij onduidelijk.

Renderen... da's dan weer andere koek. De rendertijden van een simpel vijf minuten clip met een enkel titeltje en een paar crossfades is toch al gauw meer dan een half uur. Dat is dan renderen naar een vergelijkbaar HD formaat, hetzij in mpg hetzij in flv/f4v. Renderen naar standaard DV of MPG2 voor SD DVD gaat sneller.

Overigens l'histoire se repete: ik kan me de discussie over al die crappy firewire insteekkaarten van 10 jaar terug nog herinneren. Wat een gedoe het toen was om fatsoenlijk DV materiaal te bewerken....

[Anoniem: 22659]

Mbt het RAMdisk verhaal: indien de doorvoersnelheid van een HDD de bottleneck zou kunnen vormen bij het renderen dan zou een kleine file van zo'n 500 MB alsnog snel gerenderd moeten worden. In het slechtste geval zou je een slechte HDD hebben van 50MB/s. Stel je voor dat je op dezelfde HDD leest en schrijft, dan blijft er 25 MB/s over. Dan zou je (als het zoveel uitmaakt) binnen 20 sec een dergelijke file kunnen renderen. Dit is niet het geval hetgeen mij duidt dat de snelheid van een HDD nauwelijks nog van invloed kan zijn.

Of maak ik nu een enorme denkfout?

[kluyze]

Het zou kunnen, zoals ik al zei ben ik niet zo thuis in dat soort zaken, het was alleen mijn gevoel met de bestanden die ik heb omgezet. Misschien waren de bestanden niet groot genoeg en was het grootste gedeelte in beslag genomen met lezen en schrijven van de disk.
De ramdisk is natuurlijk ook maar 4GB dus een DVD of groter kan ik niet proberen om zowel te lezen als te schrijven van die ramdisk.

i7 920 draait trouwens op 3.6GHz (+turbo) dus die gaat er ook wel tegen aan. Ik weet ook niet welke codec multicore ondersteund en welke codec zelfs gebruik kan maken van mijn 4890. Dat zijn volgens mij ook wel zaken die een invloed kunnen hebben. Nog meer volgens mij als een upgrade van een E8400 naar een i7 920 of hoger bv. Wat ben je aan een i7 als je codec maar 1 core gebruikt.
Zo zie ik bv dat als ik een AVI naar mpeg4 (.3gp) omzet dat mijn 8 'cores' maar voor 25-40% belast zijn. Is dat dan een teken dat mijn cpu ergens door een ander onderdeel tegen gehouden wordt of is de gebruikte codec slecht geschreven. Maar zou die dan niet eerder 1 core vol belasten? Het lijkt me dat de software wel ge-thread is maar dat de threads niet volluit kunnen gaan omdat ze op of elkaar of op iets anders moeten wachten. Zoals bv de hdd.

[dion_b]

Anoniem: 22659 schreef op woensdag 06 januari 2010 @ 17:16:
Mbt het RAMdisk verhaal: indien de doorvoersnelheid van een HDD de bottleneck zou kunnen vormen bij het renderen dan zou een kleine file van zo'n 500 MB alsnog snel gerenderd moeten worden. In het slechtste geval zou je een slechte HDD hebben van 50MB/s. Stel je voor dat je op dezelfde HDD leest en schrijft, dan blijft er 25 MB/s over. Dan zou je (als het zoveel uitmaakt) binnen 20 sec een dergelijke file kunnen renderen. Dit is niet het geval hetgeen mij duidt dat de snelheid van een HDD nauwelijks nog van invloed kan zijn.

Of maak ik nu een enorme denkfout?

Je maakt een enorme denkfout

Wat je hier zegt zou opgaan als je bij het renderen simpelweg het bestand éénmalig in zou laden en verder niet meer aan zou komen. Daarnaast moet je laadtijd en daadwerkelijke rendertijd niet door elkaar halen. Als je de laadtijd met een factor 50 verlaagt, doe je nog niets met de tijd dat de CPU aan het renderen is. Maar je zorgt er wel voor dat hij veel sneller kan beginnen ermee.

Waarschijnlijk kun je het beter voorstellen als dat 50% van de performance afhangt van HDD en 50% van CPU. Gevolg van het vermorzelen van de HDD bottleneck is gewoon dat het relatief nog meer van de CPU af gaat hangen.

[druipgrot]

Hoop dat deze discussie niet is afgelopen. En als het antwoord voor de ingewijden al helder is, dat iemand dat nog even helder samenvat. Onder Processors, Moederborden en Geheugen heb ik een ver verwante vraag aan de orde gesteld en daar houdt de respons ook niet over. On topic:

dion_b schreef op woensdag 06 januari 2010 @ 13:25:
[...]

Dit bevestigt iig zeer duidelijk het belang van I/O doorvoer (en geeft me trouwens gelijk een tip uit een 100% vergelijkbare situatie (hard- en software) om aan die kennis met 12GB door te geven voor hoe hij die RAM wel degelijk nuttig kan inzetten )

Edit:
WTF? Vista heeft geen native ramdisk mogelijkheid? Dat kon onder DOS al ffs

Hoe heb jij die ramdisk aangemaakt?

Kun je iets meer uitweiden over het belang van die I/O doorvoer en dat bijv. illustreren aan de hand van hoe daarin de chipsets P55 en X58 scoren?

[kluyze]

Als ik even mag:

Aangezien je hdd de traagste component in je pc is gaat meestal bij lees- en schrijfacties je hdd de bottleneck zijn. Bij een ssd is dit bv al veel minder.

De IO doorvoor is natuurlijk hoe snel dat er naar de opslagmedia geschreven en gelezen kan worden. Dit heeft voornamelijk te maken met wat voor controller er zit en hoe snel deze aangestuurd kan worden vanuit de cpu. Ook het type media kan hierin uitmaken.

Ik denk dat hoewel elke chipset zijn eigen specificaties heeft en dus er een verschil kan zitten in snelheden de grootste factor hier toch de controller is. De P55 en de X58 gaan volgens mij hierin geen merkbare rol spelen. Ze zullen indien ze dezelfde controller (zouden) hebben, ongeveer dezelfde prestaties kunnen neerzetten.
Wat eventueel een verschil kan uitmaken is dat als ik me niet vergis bij de p55, eigenlijk de So1156 cpu's een pci-ex controller in de cpu hebben zitten en zo lagere latency's hebben. Hierdoor kan het zijn dat je betere resultaten behaalt met een sata controller op pci-ex.

Belangrijker is dus de controller. En hoe snel die de data kan doorsturen en hoe hard die de cpu kan ontlasten. Dan ga je een verschil maken tussen een aantal types.

* Je hebt de onboard sata controller die op elk moederbord zit. Bv bij de X58 is dat dikwijls de Intel ICH10R. Die kan bv in raid maximaal 500-600MBps naar de sata disken sturen.

* Je kan ook een los kaartje kopen. Maar daarin heb je natuurlijk ook veel verschil. Sweex heeft sata controllers die in mijn ogen zowat budget zijn. Dan heb je de wat zwaardere sata/raid controllers die ook weer wat duurder zijn zoals de promise ed. kaartjes. En dan heb je waarschijnlijk nog snellere kaarten die voor de gemiddelde consument niet betaalbaar zijn.

Natuurlijk speelt de media ook mee. Je heb een aantal opslag media (harde schijven)

* Je kan een reguliere hdd gebruiken, die zijn voornamelijk goedkoop voor massa opslag. Maar daar heb je nog verschil tussen bv een wat tragere 5400rpm WD green die voornamelijk stil en koel blijft. Of een snelle Samsung Spinpoint F3 of WD Black.

* Dan zijn er nog de 10krpm schijven als de WD raptors die kwa sequentiele snelheden ongeveer evenwaardig misschien iets sneller zijn als de snellere 7200rpm schijven maar die lagere toegangstijden hebben waardoor ze beter met kleinere bestanden om kunnen.

* Iets sneller staan de SSD's, die hebben dikwijls een stuk hogere sequentiële snelheden. Factor 2-3 tov andere reguliere hdd's en ook een zeer lage toegangstijd waardoor deze nog een heel stuk sneller zijn als raptors. Het nadeel hier is dat beschreven cellen herschrijven traag is en dat je dus moet oppassen met degradatie. Een voorbeeld van een ssd die weinig last heeft van degradatie en technieken ondersteund om dit tegen te gaan is de X25-M van intel.

* En dan heb je als laatste nog wat ik aanhaalde, een ramdisk. Daarvoor kan je een stukje hardware halen zoals de iram van Gigabyte maar die hebben het nadeel dat ze op de sata controller zitten en dus minder snel zijn. Beter zou zijn een ramdisk die rechtstreeks op een pci-ex 4x of hoger zit. Maar die zijn duur en zo goed als niet te vinden. iram bestaat ook op pci(-ex) maar dat is alleen voor de voeding, de data gaat nog over een sata controller.
Of je doet zoals mij, je gooit er een sloot ram in bv 12GB en je stelt een programma in dat een virtuele disk maakt in het ram geheugen die snelheden van +5GBps sequentieel haalt.

Nu dit topic is er om te kijken wat voor oplossingen (hardware/software) iets betekenen voor het afspelen en monteren van HD materiaal dus wat juist die IO doorvoer betekent voor die zaken is nog niet bekent. Maar daar proberen ze hier achter te komen.
Maar wat van belang lijkt te zijn is dus de toegangstijden. Een ramdisk heeft een zeer lage toegangstijd en dus kan die heel snel kleine bestanden schrijven en lezen. En wat dion_b zegt is dat tijdens het omzetten/monteren er continu van de media gelezen wordt. Indien dit sequentieel zou gebeuren is vooral de sequentiële snelheid van de media belangrijk maar indien de software veel kleine lees acties doet dan gaat de toeganstijd van de media een grotere rol spelen. En heeft de cpu dus een meer continue aanvoor van data.

Edit:
Dit wou ik toch ook nog vermelden:
De harde schijven in je pc dienen voor een aantal zaken. Je gebruikt dat als opslag van documenten en dergelijke. Hiervoor is de snelheid niet zo belangrijk.

Verder staat er je besturingsysteem op, hiervoor is voornamelijk de random read belangrijk. Hoe sneller de random read van de harde schijf, hoe sneller windows reageert, hoe sneller applicaties opgestart zijn ed. Hierdoor heeft een ssd nogal wat voordelen.

Maar je harde schijf wordt ook gebruikt als uitbreiding van je ram geheugen. Je cpu gaat namelijk data moeten verwerken, die data gaat hij eerst halen uit he L1 cache (snel maar klein geheugen), als dat vol is gaat hij kijken in het L2 daarna indien het bestaat L3 die telkens wat groter zijn maar ook trager. Als hij daar de data niet vindt gaat hij kijken in het ram geheugen, dat is een heel stuk groter maar tov het L1 bv een heel stuk trager. Is de data hier ook niet te vinden dan gaat hij kijken in de swap file op de hdd/ssd.

Djeezus wat een lap tekst heb ik me nu getypt. Ik wist dat het lang was maar zo lang? Ik hoop dat ik nergens flaters gezet heb, anders verbetert iemand me maar. Als iemand de moeite gaat nemen om het helemaal te lezen

[ Voor 18% gewijzigd door kluyze op 08-01-2010 09:29 ]

[Anoniem: 22659]

kluyze schreef op vrijdag 08 januari 2010 @ 09:05:

Djeezus wat een lap tekst heb ik me nu getypt. Ik wist dat het lang was maar zo lang? Ik hoop dat ik nergens flaters gezet heb, anders verbetert iemand me maar. Als iemand de moeite gaat nemen om het helemaal te lezen

Uiteraard lees ik iedere reactie En een lange reactie lees ik extra goed, want dan heeft iemand echt zitten broeden

Wat ik opmaak uit jouw verhaal is dat de snelheid van een HDD op twee vlakken belangrijk is, random acces en sequentiele doorvoersnelheid (ik ben wel redelijk thuis in HDD land, dus voor zover niets nieuws). Ik beaam ook zeker de stellingen die je doet, alleen zit ik nog vast een stapje ervoor, namelijk is de invloed van een HDD/IO systeem uberhaupt significant van invloed op de prestaties van het tonen van een AVCHD bestand en het monteren ervan.

Zoals ik reeds eerder heb aangegeven is de maximale bitrate van AVCHD slechts 24 mbits/s. Dat levert je een schamele 3 MB/s. In theorie moet een compleet afgeladen HDD van een oude laptop nog een dergelijke prestatie leveren imo. Daarnaast betreft het een enkel -of in een ongunstig geval een gelimiteerd aantal- bestand(en). Dat lijkt ook de random access time uit te sluiten. Nadeel is dat ik geen idee heb wat de computer doet tijdens het renderen en of dit verhaal dan ook nog opgaat.

Eigenlijk zouden we dit eens moeten laten testen door iemand die diverse interne HDDs heeft. In dat geval blijven alle zaken hetzelfde, behalve de HDD snelheid.

[kluyze]

Anoniem: 22659 schreef op vrijdag 08 januari 2010 @ 09:57:
[...]

Zoals ik reeds eerder heb aangegeven is de maximale bitrate van AVCHD slechts 24 mbits/s. Dat levert je een schamele 3 MB/s. In theorie moet een compleet afgeladen HDD van een oude laptop nog een dergelijke prestatie leveren imo. Daarnaast betreft het een enkel -of in een ongunstig geval een gelimiteerd aantal- bestand(en). Dat lijkt ook de random access time uit te sluiten. Nadeel is dat ik geen idee heb wat de computer doet tijdens het renderen en of dit verhaal dan ook nog opgaat.

Ja bij het gewoon afspelen van een bestand van je hdd gaat er waarschijnlijk niet zo zeer een hdd bottleneck zijn.

Maar ik weet ook niet wat er in de achtergrond gebeurd bij renderen en andere bewerkingen.
Probleem is voor mij ook nog dat ik niet zo thuis ben in die materie en dus ook niet onmiddelijk weet of ik de juiste instellingen gebruik om te testen.
Gaat zo bv een conversie van een divX avi naar een mpeg4 3gp bestand een goede indicatie zijn? Ik heb zo al eens een avi van 800Kbps omgezet naar een 3gp van 6MBps (iets hogere resolute) en ik merkte dat van ram naar ram een stuk sneller ging. (ik schat een uur winst op een totale tijd van 3-4u)

Maar is alleen een conversie doen een goede indicatie om te vergelijken met monteren. En wat als dan bij het monteren geen conversie plaats vind? En is het dan interessant als test om ook te conversie naar een hogere resolutie?

Dan is er natuurlijk ook nog de vraag wanneer er een bottleneck optreed aan de kant van de opslagmedia. Mijn i7 920 moet misschien wachten op de hdd. Terwijl een athlon 64 x2 4400+ of iets dergelijks de data niet snel genoeg kan behandelen om te moeten wachten op de hdd. Het wilt niet zeggen omdat een component het traagste onderdeel in de pc is dat daarom altijd die componenten de bottleneck vormen.

[ Voor 11% gewijzigd door kluyze op 08-01-2010 11:07 ]

[Anoniem: 22659]

kluyze schreef op vrijdag 08 januari 2010 @ 11:00:

Probleem is voor mij ook nog dat ik niet zo thuis ben in die materie en dus ook niet onmiddelijk weet of ik de juiste instellingen gebruik om te testen.

Wat mij betreft is dat een onderdeel van de discussie. Aangezien het gaat om de minimale systeemeisen denk ik dat we het niet te moeilijk moeten doen en ervan uitgaan dat je een klein aantal AVCHD bestanden hebt die je achter elkaar wilt zetten (misschien inkorten) en tot een nieuw bestand wilt maken (het maakt mij even niet zozeer uit welke type).

Maar is alleen een conversie doen een goede indicatie om te vergelijken met monteren. En wat als dan bij het monteren geen conversie plaats vind? En is het dan interessant als test om ook te conversie naar een hogere resolutie?

Een hogere resolutie lijkt me niet. We werken al op 1920x1080 Waar het imo om gaat is dat je de geselecteerde bewerkingen vloeiend kunt doen. Daarnaast is een indicatie van de rendertijd ook wel leuk, maar dat is meer indicatief, aangezien dat in theorie door een extreem trage pc kan gebeuren.

Ik denk ook dat we niet hoeven te streven naar een montage met allerlei effecten. Als mensen extreme eisen hebben mbt de effecten dan moeten ze niet kijken naar het minimale systeem Dit is meer bedoeld voor de normale huis-tuin-en-keuken filmpjes wmb.

[M2M]

kluyze schreef op vrijdag 08 januari 2010 @ 11:00:
[...]

Maar ik weet ook niet wat er in de achtergrond gebeurd bij renderen en andere bewerkingen.
Probleem is voor mij ook nog dat ik niet zo thuis ben in die materie en dus ook niet onmiddelijk weet of ik de juiste instellingen gebruik om te testen.
Gaat zo bv een conversie van een divX avi naar een mpeg4 3gp bestand een goede indicatie zijn? Ik heb zo al eens een avi van 800Kbps omgezet naar een 3gp van 6MBps (iets hogere resolute) en ik merkte dat van ram naar ram een stuk sneller ging. (ik schat een uur winst op een totale tijd van 3-4u)

dat vind ik nu vreemd. Een beetje harde schijf kan echt wel een read stream van 800 Kilobits/s en een write stream van 6 MegaByte/s aan. Dus tenzij de encoder die je gebruikt hebt (je hebt toch ge-encode, en niet enkel de container verwisseld?) na elk stukje encoden, zowel een leesactie, als eens schrijfactie richting een schijf stuurt lijkt het mij redelijk lastig te begrijpen dat je er 25% winst mee kunt maken.
Encoderen (of beter, recoderen, want niemand codeert vanaf uncompressed AVI) heeft voornamelijk met cpu cycles te maken. Mijn home-video projectje als cadootje voor mijn ouders, koste 2 uur om te coderen richting 720P Xvid, vanaf voornamelijk windows media HD format. En dat was maar 15 minuten film, met een bestandsgrootte van 200 MB. Het lijkt mij heel sterk dat een moderne schijf geen 2 Gigabyte (originele formaat van het totaal van alle kleine filmpjes) kan lezen en 200 MB kan schrijven in 2 uur.
Ps. mijn processor is een E8400 op 4 GHz.

edit: de harde schijf in kwestie was een spinpoint F1 van samsung, waar ik eigenlijk over het gehele tijdsbestek een 70 - 80% cpu verbruik heb gezien tussen twee processen. Blijkbaar 1 leesprocess en een encodeerprocess, waarbij het leesprocess ook de filters en vervormingen in de video voor zijn rekening nam. HD activiteit was er nauwelijks.

Maargoed, voor IO throughput is een oplossing. Knikker twee SSD's in een systeem, waarbij je eentje gebruikt als tijdelijke leesdisk, en eentje gebruikt als tijdelijke schrijf disk. In combinatie met een normale harde schijf voor de wat langere storage heb je genoeg IO ruimte om je processor de bottleneck van alle video-recodering te laten zijn.

Voor de rest zou het natuurlijk leuk zijn om een stukje software (plugin?) te vinden die ook van je gpu gebruik kan maken. Iets wat photoshop als ik me niet vergis al doet. Aangezien je GPU gemaakt is voor pixelbewerkingen en tegenwoordig het meest simpele exemplaar al een videostream kan decoderen, is zo'n apparaat natuurlijk uitermate geschikt voor videobewerking. Het enige wat nog gedaan moet worden door de cpu is het encoderen van je materiaal. En dat is eigenlijk best goed te splitsen, want als je decodeerproces enorm snel kan verlopen, en je genoeg geheugen hebt om een tijdsspan tussen 8 keyframes, in uncompressed formaat, in buffer op te slaan, kun je dus ook 8 processor(core)s tegelijk aan het werk zetten om de stukken tussen de keyframes te encoderen.

want wat ik gemerkt heb bij adobe premiere, is dat speciale effecten het hele encodeerproces ENORM vertragen. Dan is mijn pc wel een minuut bezig per frame. Ook versneld afspelen, of langzamer afspelen is erg zwaar voor de encoder. En dat was pas op 720P...

[ Voor 6% gewijzigd door M2M op 08-01-2010 11:31 ]

[kluyze]

Anoniem: 22659 schreef op vrijdag 08 januari 2010 @ 11:10:
[...]

Een hogere resolutie lijkt me niet. We werken al op 1920x1080 Waar het imo om gaat is dat je de geselecteerde bewerkingen vloeiend kunt doen. Daarnaast is een indicatie van de rendertijd ook wel leuk, maar dat is meer indicatief, aangezien dat in theorie door een extreem trage pc kan gebeuren.

[...]

Ok, hoger als 1920x1080 is niet nuttig maar ik bedoelde eigenlijk dat ik een bestand had van 800Kbps, dus niet zo veel en dat heb ik omgezet naar een resolutie die beter oogde op mijn gsm en in dat geval was die resolutie hoger als het originele bestand. Ik mijn vraag was dan of het iets uitmaakt kwa cpu belasting of je een bestand op een hogere resolute brengt of een lagere. Op een hogere reolutie moeten er pixels bij verzonnen worden welke berekend moeten worden adv de omliggende pixels, terwijl bij een lagere resolutie vallen er pixels weg en dan moet er een berekening komen om toch niet te veel informatie te laten vallen.
Maar wat is dan intensiever en mag je het resultaat van de ene test gebruiken om een voorspelling doen in de andere test?

M2M schreef op vrijdag 08 januari 2010 @ 11:27:
[...]

dat vind ik nu vreemd. Een beetje harde schijf kan echt wel een read stream van 800 Kilobits/s en een write stream van 6 MegaByte/s aan. Dus tenzij de encoder die je gebruikt hebt (je hebt toch ge-encode, en niet enkel de container verwisseld?) na elk stukje encoden, zowel een leesactie, als eens schrijfactie richting een schijf stuurt lijkt het mij redelijk lastig te begrijpen dat je er 25% winst mee kunt maken.

Dat zou ik in eerste instantie ook zeggen, dus of die test is niet representatief of er gaan bij het re-coderen veel kleine stukjes data geschreven worden (telkens een read-append-write?) of er iets nog iets anders gaande natuurlijk.
Verder lijkt het me dat indien ik van een divx avi naar een mpeg4 3gp bestand ga of van een .mov naar een divx avi, dat er niet alleen de container veranderd is? Maar daar kan ook wel mis in zijn aangezien ik zoals eerder gezegd niet zo thuis ben in dat soort zaken.

Encoderen (of beter, recoderen, want niemand codeert vanaf uncompressed AVI) heeft voornamelijk met cpu cycles te maken. Mijn home-video projectje als cadootje voor mijn ouders, koste 2 uur om te coderen richting 720P Xvid, vanaf voornamelijk windows media HD format. En dat was maar 15 minuten film, met een bestandsgrootte van 200 MB. Het lijkt mij heel sterk dat een moderne schijf geen 2 Gigabyte (originele formaat van het totaal van alle kleine filmpjes) kan lezen en 200 MB kan schrijven in 15 minuten.
Ps. mijn processor is een E8400 op 4 GHz.

Als ik benchmarks zie dan gaat een hdd soms maar 0.5MBps (1.2MBps voor een raptor bv.) max kunnen lezen en schrijven als het gaat om bestand groottes van 4kB. 2GB tegen pak 60MBps geeft 33s en dan 200 MB tegen 0.5MBps is nog eens 400s. Samen 430s geeft 7 minuten. Die 2GB in kleinere bestanden kan het lezen nog wat vertragen maar inderdaad geen extra 7 minuten.
Maar het kan wel zijn dat de software niet alles tegelijk leest maar alleen de stukjes die nodig zijn, wanneer ze nodig zijn. Op dat moment gaat de cpu moeten wachten met rekenen tot het volgende stukje gelezen is en gaat bij een traditionele hdd de toegangstijd van soms zelfs 20-25ms mee tellen. Ook als de software na de berekening eerst het stukje weg wilt schrijven voor hij een nieuw deel gaat lezen krijg je weer die vertraging. Op dat moment moet je bij het lezen ook niet meer de sequentiele snelheid tellen maar die 2GB tegen 0.5MBps en dat geeft 4000 seconden, of 66 minuten. Dus van die 2u om te converteren zou er iets meer als een uur gebruikt zijn om te lezen en schrijven en net onder het uur om het omzetten door de cpu zelf.

Ik weet dus niet of dat dit een berekening is die juist is. En of die waardes realistisch zijn, ze komen dan ook uit een synthetische benchmark. Misschien gaat het iets sneller en is de verhouding eerder meer naar de cpu tijd maar het zou wel kunnen verklaren waarom ik zo veel snelheidswinst voel met een ramdisk. Maar het zou dus ook kunnen dat ik mis ben en dat ik ergens iets verkeerd doe.
Daarom dat ik hier het topic ook wil volgen om bij te leren en waar kan eventueel zelf input kan geven die bevestigd kan worden of tegengesproken.

Voor de rest zou het natuurlijk leuk zijn om een stukje software (plugin?) te vinden die ook van je gpu gebruik kan maken. Iets wat photoshop als ik me niet vergis al doet.

photoshop kan dat inderdaad ja, voor bepaalde bewerkingen. Premieren pro gebruikt als ik me niet vergis de codec van derden (ik moest quicktime installeren om premiere .mov te laten lezen) dus als die software van derden de gpu kan gebruiken dan kan premiere dit ook.

[ Voor 4% gewijzigd door kluyze op 08-01-2010 12:03 ]

[druipgrot]

kluyze schreef op vrijdag 08 januari 2010 @ 09:05:Djeezus wat een lap tekst heb ik me nu getypt. Ik wist dat het lang was maar zo lang? Ik hoop dat ik nergens flaters gezet heb, anders verbetert iemand me maar. Als iemand de moeite gaat nemen om het helemaal te lezen

Tuurlijk lees ik dat, het was een lekker ontbijt, dank je!
(Verder moet ik het laten bezinken, denk dat ik voor de optie van 12GB RAM ga.)

[dion_b]

M2M schreef op vrijdag 08 januari 2010 @ 11:27:
[...]


dat vind ik nu vreemd. Een beetje harde schijf kan echt wel een read stream van 800 Kilobits/s en een write stream van 6 MegaByte/s aan. Dus tenzij de encoder die je gebruikt hebt (je hebt toch ge-encode, en niet enkel de container verwisseld?) na elk stukje encoden, zowel een leesactie, als eens schrijfactie richting een schijf stuurt lijkt het mij redelijk lastig te begrijpen dat je er 25% winst mee kunt maken.

Latency, latency, latency

Iedere HDD kan tegenwoordig sustained reads van >40MB/s aan, vaak zelfs het drievoudige. Bepalend voor linear read performance is overigens de dichtheid van de data op de platters. Hierin scoren grote schijven bijna altijd het beste - een 2TB WD Green 5400rpm doet het even goed als of zelfs beter dan een 300MB Velociraptor.

Voor linear writes geldt hetzelfde, datadichtheid is bepalend voor performance.

Maar...

Zodra je data niet netjes liniair (sequentieel) zit, moeten de heads heen en weer schipperen. En dan zit je met enorme vertraging. Zo'n 2TB WD Green heeft latencies van rond de 6ms. In die tijd had de schijf (bij 120MB/s throughput) 0.72MB kunnen lezen, maar doet het dat niet. Die Velociraptor heeft latencies van rond de 3ms, waardoor het slechts 0.36MB mist, terwijl een SSD latencies heeft die je niet in ms maar ns meet, met gevolg dat je bij benadering niet mist.

Voor writes ligt de situatie iets minder zwart-wit, 5400rpm vs 10k levert nog steeds een 2:1 verhouding op qua latencies, maar omdat de SSDs grotere blokken schrijven dan dat ze lezen zijn random writes veel minder spectaculair dan random reads. Dat gezegd, een X25-M zou nog steeds VEEL minder latency hebben dan een Velociraptor (maar een JMicron-based SSD zou slechter zijn dan een 4200rpm Quantum Bigfoot uit 1995 )

Nu ben je bij het bewerken simultaan aan het lezen en schrijven. Dat betekent per definitie dat die koppen steeds heen en weer aan het springen zijn. Die kleine latencies stapelen zich dan op om performance te impacten. Hoe groot die impact is hangt er maar vanaf. SSDs hebben simpelweg geen significante read latency, dus scoren (mits geen JMicron) in theorie het best. SATA schijven met NCQ zouden opdrachten op moeten sparen en moeten ordenen op een manier dat zo min mogelijk kopbewegingen oplevert, en PATA of non-NCQ SATA schijven zouden de meeste problemen moeten hebben omdat ze alles in de toevallige volgorde waar ze requests binnenkrijgen moeten afhandelen.

Maar goed, dat is puur theorie - maar wel degelijk theorie dat kan verklaren waarom er zo'n verschil tussen HDDs kan zitten.

Het lijkt mij heel sterk dat een moderne schijf geen 2 Gigabyte (originele formaat van het totaal van alle kleine filmpjes) kan lezen en 200 MB kan schrijven in 2 uur.

2GB lezen en 200MB schrijven in 2 uur is triviaal als je eerst 2GB inleest, dan 200MB schrijft, maar als je het beide tegelijk doet wordt het minder triviaal. Vergelijk het met een verkeersplein. 2000 auto's in de ene richting en 200 auto's in de andere is geen enkel probleem als ze niet tegelijkertijd gaan, maar als ze door elkaar heen willen kun je files krijgen, en dan zit een Ferrari net zo goed vast als een Fiat

Anoniem: 22659 schreef op vrijdag 08 januari 2010 @ 09:57:
[...]

Eigenlijk zouden we dit eens moeten laten testen door iemand die diverse interne HDDs heeft. In dat geval blijven alle zaken hetzelfde, behalve de HDD snelheid.

* dion_b volunteers!

Eergisteren heb ik eindelijk mijn nieuwe PC binnen. Helaas bleek RAM niet met mobo compatible ( etc ), daar ga ik vandaag iets aan doen, dus met beetje geluk heb ik dit weekend een bak liggen met een schone install Windows 7 (en kort na het weekend ook Gentoo Linux) dat iig ideaal is voor wat I/O tests. Het gaat namelijk om een i7 860-based systeem, wat qua CPU iig "snel" mag heten, met 4GB RAM (niet genoeg voor RAMdisk, wel genoeg om geen major bottleneck te vormen), 80GB Intel X-25M G2 SSD, 1TB Samsung F1 7200rpm SATA HDD, en (niet vast onderdeel van de bak, maar toevallig wel gisteren dankzij Terw_Dan geregeld) een 60GB Seagate 4200rpm laptop schijf, die model kan staan voor de "worst case scenario" van een goedkope netbook oid.

Probleem: extreem weinig kennis omtrent videobewerking, en geen software.

Als iemand het volgende zou kunnen uitzoeken, dan kan ik iig benchen met 3 verschillende types opslag en twee OSsen:
- een gratis (liefst FOSS, liefst ook cross-platform ivm vergelijking met Linux) prog voor de bewerking
- een bronbestand die we als "standaard" kunnen gebruiken
- een script van handelingen die ik moet volgen (of nog beter: een geautomatiseerde benchmarkscript) om de boel te testen

[Exocet]

dion_b schreef op vrijdag 08 januari 2010 @ 12:52:
[...]

Als iemand het volgende zou kunnen uitzoeken, dan kan ik iig benchen met 3 verschillende types opslag en twee OSsen:
- een gratis (liefst FOSS, liefst ook cross-platform ivm vergelijking met Linux) prog voor de bewerking
- een bronbestand die we als "standaard" kunnen gebruiken
- een script van handelingen die ik moet volgen (of nog beter: een geautomatiseerde benchmarkscript) om de boel te testen

Misschien is dit iets voor het benchmarken?
http://tweakers.net/benchdb/test/289

[Anoniem: 22659]

dion_b schreef op vrijdag 08 januari 2010 @ 12:52:

Latency, latency, latency
Enz...

Allereerst dank voor je goede bijdrage in de diiscussie

Zou dat betekenen dat een tweede HDD per definitie veeel sneller moet renderen?

Als iemand het volgende zou kunnen uitzoeken, dan kan ik iig benchen met 3 verschillende types opslag en twee OSsen:
- een gratis (liefst FOSS, liefst ook cross-platform ivm vergelijking met Linux) prog voor de bewerking

FOSS?

- een bronbestand die we als "standaard" kunnen gebruiken

Dit was een beetje een punt van me, aangezien ik zelf alleen maar tot 17mbit/s kan opnemen. Ik zat erover te denken om een trailer van het een of ander te pakken. Ik vraag me alleen af hoe dat met copyright gaat!

Exocet schreef op vrijdag 08 januari 2010 @ 12:57:

Misschien is dit iets voor het benchmarken?
http://tweakers.net/benchdb/test/289

Goed idee om dat te standariseren, maar ik heb geen idee hoe dat werkt. Of is dat deel van tweakers alleen voor het uploaden van resultaten?

[M2M]

dion_b schreef op vrijdag 08 januari 2010 @ 12:52:
[...]

Latency, latency, latency

Iedere HDD kan tegenwoordig sustained reads van >40MB/s aan, vaak zelfs het drievoudige. Bepalend voor linear read performance is overigens de dichtheid van de data op de platters. Hierin scoren grote schijven bijna altijd het beste - een 2TB WD Green 5400rpm doet het even goed als of zelfs beter dan een 300MB Velociraptor.

Voor linear writes geldt hetzelfde, datadichtheid is bepalend voor performance.

Maar...

verhaal om het niet zo'n lang bericht te laten zijn,

Dit had ik dus meegenomen in mijn schatting. Ik zet regelmatig schrijf en leesacties tegelijk aan om data van disk naar disk te verplaatsen. Disks die ik niet defragmenteer omdat ik dat te veel tijd vind kosten. Natuurlijk geen objectieve benadering, maar goed genoeg om te zien dat je wel 2x10 GB kunt kopieëren vanaf en naar een schijf toe in een uur (= zo ongeveer de tijd onder het avondeten)

Sowieso gaan we toch niet uit van een schijf vol met gaten die eerst netjes opgevuld worden met data? Het zou daarnaast ook slecht zijn als een video encoding programma van tegenwoordig pas een leesactie gaat doen wanneer de data echt nodig is, en vervolgens een append doet tegelijk met een leesactie, omdat de brakke software nu eenmaal tegelijk klaar is met het encoden van een stel frames, als het nieuwe data nodig heeft. Dan lopen de lees en schrijf threads constant op elkaar te wachten . Twee buffers, een output en een input buffer, al is het maar 50 MB zou al voldoende moeten zijn om die schijf niet de bottleneck te laten zijn. (= lees zelfs een antieke quantum schijf)

2GB lezen en 200MB schrijven in 2 uur is triviaal als je eerst 2GB inleest, dan 200MB schrijft, maar als je het beide tegelijk doet wordt het minder triviaal. Vergelijk het met een verkeersplein. 2000 auto's in de ene richting en 200 auto's in de andere is geen enkel probleem als ze niet tegelijkertijd gaan, maar als ze door elkaar heen willen kun je files krijgen, en dan zit een Ferrari net zo goed vast als een Fiat

Tja, files. Ongeveer hetzelfde als een dvd op 16 speed branden als je data gefragmenteerd is over de gehele schijf in 5000 stukjes. Dan zie je ook leuk de leesbuffer teruglopen tot 0, waarna de buffer van de brander er mee ophoud en het gehele brandproces stilgezet wordt. Maar zelfs dan, is dit toch heel gemakkelijk te omzeilen door een andere schijf te gebruiken als "schrijfschijf" en eentje als leesschijf? Dat doe je ook als veel data uitpakt, lezen op de ene schijf, schrijven op de andere. Anders loopt het allemaal in de soep omdat winrar niet gebruik kan maken van bijvoorbeeld een 4 GB buffer. Lezen (+ decoden) en daarna schrijven (eventueel ook + decoden). En dan die buffer weer volgooien met lees-IO.

Maargoed, ik ben uiteraard het helemaal eens met benchmarks. Mijn schatting is dat een degelijke encoder volledig CPU-snelheid afhankelijk is.

Echter ken ik zo geen cross platform encoders. Adobe kun je in ieder geval op proef gebruiken voor 30 dagen.

edit: transcoderen van AVCHD naar avi in linux: link

edit 2: FOSS:

[ Voor 3% gewijzigd door M2M op 08-01-2010 14:04 ]

[dion_b]

Anoniem: 22659 schreef op vrijdag 08 januari 2010 @ 13:45:
[...]

Allereerst dank voor je goede bijdrage in de diiscussie

Zou dat betekenen dat een tweede HDD per definitie veeel sneller moet renderen?

Als je niet alles op een SSD doet zou het inderdaad sneller zijn om je bronbestanden en werkbestanden niet op dezelfde schijven te hebben hangen. Iirc was dat de algemene bedoeling van gescheiden scratch vs. opslagschijven. Bij SSD zou het minder/niets moeten uitmaken, maar ik vraag me af hoeveel mensen zoveel SSD ruimte hebben dat ze zowel scratch als opslag op SSD kunnen houden...

[...]

FOSS?

Free & Open Source Software

[...]

Dit was een beetje een punt van me, aangezien ik zelf alleen maar tot 17mbit/s kan opnemen. Ik zat erover te denken om een trailer van het een of ander te pakken. Ik vraag me alleen af hoe dat met copyright gaat!

Vandaar m'n opmerking over FOSS

Lijkt me dat ergens wel wat spul te vinden moet zijn dat vrij bruikbaar is (iets van het Blender project?)

[ Voor 8% gewijzigd door dion_b op 08-01-2010 19:46 ]

[druipgrot]

dion_b schreef op vrijdag 08 januari 2010 @ 12:52:
[...]
Eergisteren heb ik eindelijk mijn nieuwe PC binnen. Helaas bleek RAM niet met mobo compatible ( etc ),

Nogal motiverend voor deze nitwit dat een deskundologisch iemand zo'n beginnersfout maakt... Wat staat mij dan wel niet te wachten, daarom: Ben benieuwd hoe dat zo gekomen is. succes verder met je prachtige gereedschap.

[dion_b]

druipgrot schreef op vrijdag 08 januari 2010 @ 21:00:
[...]
Nogal motiverend voor deze nitwit dat een deskundologisch iemand zo'n beginnersfout maakt... Wat staat mij dan wel niet te wachten, daarom: Ben benieuwd hoe dat zo gekomen is. succes verder met je prachtige gereedschap.

Tja, daar is een heel simpele oplossing voor: voor aanschaf de QVL bekijken en daadwerkelijk RAM daaruit kiezen. Daar heb ik 1001 keer op gehamerd bij anderen, maar uit gemakzucht zelf achterwege gelaten. Ondertussen heb ik alternatief geheugen gehaald dat wel in QVL staat en het werk allemaal prima.

Duidelijk gevalletje eigen schuld, dikke bult. Ik kon het beter weten, ik wist het beter, maar ik handelde tegen beter weten in

[kluyze]

Is er al vooruitgang geboekt in enige testen?

Ik heb ook nog een bijdrage, ik weet nog altijd niet of het enig nut heeft maar baat het niet dan schaad het niet zeker. Ik heb een film omgezet, geen fantastische kwaliteit (Weer een DivX naar mpeg4, wou een film op mijn gsm hebben en vond het een ideaal moment om de ramdisk gelijktijdig eens te monitoren) maar van ramdisk naar ramdisk. En gelijktijdig HDTune Pro laten monitoren. Hij is 2u bezig geweest.

Tijdens het omzetten was er eigenlijk continu een veel hogere read dan write op de ramdisk. De read zat op gemiddelde 5MBps met pieken tot 10MBps en een I/O van 180-210ps. Toch een redelijk hoge I/O, een reguliere hdd gaat het daar misschien moeilijk mee hebben. De write kwam niet hoger als een gemiddelde van 100kBps of zo.

Ik vind dat eigenlijk vreemd, ik kan er geen verklaring voor geven ook gezien het uiteindelijke bestand 2GB was terwijl de avi maar een 700MB dat lijkt volgensmij alsof hij delen van het originele bestand meerdere malen leest of zo?

Ik heb al eens gedacht om een dvd om te zetten maar het probleem is dat mijn ramdisk maar 4GB is en een dvd toch rap groter gaat zijn. Misschien eens tijdelijk een grotere ramdisk instellen. En gezien de vaststellingen de ramdisk alleen gebruiken om te lezen aangezien het schrijven niet de moeite is.

[wrcveen]

Het antwoord is heel simpel de nieuwste Pinnacle Studio 14 vraagt het volgende:

Intel® Pentium® of AMD Athlon™ 1.8 GHz (2.4 GHz of hoger aanbevolen) - Intel Core™ 2 Duo 2.4 GHz vereist voor AVCHD*, Intel Core™ 2 Quad 2.66 GHz of Intel Core i7 voor AVCHD* 1920

1 GB systeemgeheugen aanbevolen, 2 GB vereist voor AVCHD

Compatibele grafische kaart met DirectX® 9 of 10 met 64 MB (128 MB of hoger aanbevolen)
- 256 MB vereist voor HD en AVCHD

bron: http://www.pinnaclesys.nl...ly/Studio+Ultimate+14.htm

[Anoniem: 22659]

kluyze schreef op woensdag 13 januari 2010 @ 22:29:
Is er al vooruitgang geboekt in enige testen?

Sorry, hiervoor heb ik nog geen tijd gehad. Ben momenteel even druk met een ander project. Dit is ter voorbereiding/ter discussie van een opvolging daarvan. Het antwoord is helaas dus nog niet zo eenduidig als ik had verwacht

Ik zal eens even contact opnemen met de boys van de FP. Ik ben even benieuwd hoe die benchmarks werken. Hierin staat een Vegas benchmark voor HDDs en als we toch iets nieuws moeten maken dan maar gelijk iets dat compatible is met de FP toch?

wrcveen schreef op woensdag 13 januari 2010 @ 23:39:
Het antwoord is heel simpel de nieuwste Pinnacle Studio 14 vraagt het volgende:

Hehe, dank je wel voor je toevoeging. Helaas is het niet zo simpel, aangezien het monteren van AVCHD in pinnacle 11 ook goed gaat met een Q6600, maar ook met een AMD Athlon64 X2 5400+. Daarnaast beantwoordt dit niet de vraag over afspelen (vind ik zelf iets interessanter) Plus het zou handig zijn om de test helemaal te standaardiseren. Nu weet iemand met een snelle C2D niet of ie kan monteren in -laten we zeggen- premiere

[antiekeradio]

wrcveen schreef op woensdag 13 januari 2010 @ 23:39:
Het antwoord is heel simpel de nieuwste Pinnacle Studio 14 vraagt het volgende:

Intel® Pentium® of AMD Athlon™ 1.8 GHz (2.4 GHz of hoger aanbevolen) - Intel Core™ 2 Duo 2.4 GHz vereist voor AVCHD, Intel Core™ 2 Quad 2.66 GHz of Intel Core i7 voor AVCHD 1920

1 GB systeemgeheugen aanbevolen, 2 GB vereist voor AVCHD

Compatibele grafische kaart met DirectX® 9 of 10 met 64 MB (128 MB of hoger aanbevolen)
- 256 MB vereist voor HD en AVCHD

yep dit ziet eruit als een lijst met redelijk reele vereisten. Het is bekend dat AVCHD 1920 bewerking 'redelijk te doen' is op een Q6600 met 2GB geheugen.

Het afspelen en previewen is vooral afhankelijk van de grafische kaart (de minimum eisen lijken maar net voldoende, maar ok, het kán waarschijnlijk wel).
Het renderen hangt echt op de processorcapaciteit. Bij sommige programma's kun je GPGPU functionaliteit (zoals CUDA, OpenGL) gebruiken om bepaalde effecten door de grafische kaart te laten renderen, maar dit is beperkt tot een aantal effecten en meestal niet van toepassing voor transcoderen naar een andere codec/formaat.

Met een snellere processor dan de Q6600 (ik heb zelf een Q9550) gaat het redelijk goed. de meer recente quadcores met hyperthreading en QPI doen het nog weer een stuk beter.

Praktische advies voor mensen die AVCHD 1920 willen gaan bewerken: koop gewoon de snelste processor die je redelijkerwijs kunt betalen, zolang het Q6600 of beter is kun je ermee werken, maar sneller is altijd beter.

[Anoniem: 340014]

offtopic:
Mooi topic zeg Mig29!

[dion_b]

Anoniem: 22659 schreef op donderdag 14 januari 2010 @ 11:17:
[...]

Hehe, dank je wel voor je toevoeging. Helaas is het niet zo simpel, aangezien het monteren van AVCHD in pinnacle 11 ook goed gaat met een Q6600, maar ook met een AMD Athlon64 X2 5400+. Daarnaast beantwoordt dit niet de vraag over afspelen (vind ik zelf iets interessanter) Plus het zou handig zijn om de test helemaal te standaardiseren. Nu weet iemand met een snelle C2D niet of ie kan monteren in -laten we zeggen- premiere

^^

With stupid


Zelf ben ik op het werk meermaals betrokken geweest bij het bepalen van minimumspecs voor iets commercieels, en het is altijd een kwestie van compromis tussen technische eisen (wat werkt?), commerciele eisen (wat kun je nog verkopen?) en klantcommunicatie (hoeveel nuances snapt een klant voordat hij afhaakt?).

Vooral die laatste is fnuikend. Als je meer dan een handjevol variabelen noemt, kan bijna geen enkele leek het volgen. Helaas is de realiteit (zoals hier goed blijkt) veel complexer en spelen er verschillende variabelen op verschillende manieren mee.


Hier speelt dat je definitie van wat acceptabel is volledig bepalend is voor welke specs je noemt. Gaat het om het überhaupt kunnen draaien van het programma? Of om vloeiende montage te kunnen doen? Of om te kunnen renderen op zeer hoge snelheid? Elk van die drie heeft radikaal andere eisen, waarbij de laatste twee ook nog eens andere prio geven aan andere onderdelen (EUR 100 meer aan CPU uitgeven zou voor renderen handig kunnen zijn EUR 100 meer aan I/O voor montage, bijvoorbeeld).

Voordat we ook maar iets met specs kunnen roepen moet je dus een definitie hebben, waarin gebruikte software (OS, CODEC en bewerkingsprogramma), gebruikte bronbestanden en gebruikte hardware vast moeten liggen.

[druipgrot]

nvt

[ Voor 185% gewijzigd door druipgrot op 16-01-2010 13:57 . Reden: achteraf beschouw ik het ingestuurde bericht als minder constructief/toepasselijk ]

[M2M]

dus pinnacle studio 14 kan dus wel gebruik maken van de features van de GPU? omdat daarvoor een specifieke DX9 kaart gevraagd wordt. (maar dat kan natuurlijk ook een crappy onboard chip zijn, wat dan met het toevoegen van effecten niet zo heel veel doet.

[Cablekevin]

Heb op het moment het volgende in bestelling:

Intel i7 920
Asus Rampage II GENE
6GB Corsair Dominator 1600Mhz (7-7-7-20)
XFX ATI Radeon 5850 Black Edition

Eens kijken hoe CS4 premiere hierop gaat reageren i.c.m. met mijn Sony AVCHD camcorder.

[ Voor 0% gewijzigd door Cablekevin op 18-01-2010 14:37 . Reden: 7-7-7-20... ]

[martin2005]

Cablekevin schreef op maandag 18 januari 2010 @ 14:36:
Heb op het moment het volgende in bestelling:

Intel i7 920
Asus Rampage II GENE
6GB Corsair Dominator 1600Mhz (7-7-7-20)
XFX ATI Radeon 5850 Black Edition

Eens kijken hoe CS4 premiere hierop gaat reageren i.c.m. met mijn Sony AVCHD camcorder.

[jaloers]Damn[/jaloers]
ok, reality check.. kost dat nou bij elkaar?

[Anoniem: 22659]

martin2005 schreef op maandag 18 januari 2010 @ 17:14:

ok, reality check.. kost dat nou bij elkaar?

Zie http://tweakers.net/pricewatch/

Ik heb inmiddels een mail verstuurd naar de boys van de benchmarks, dus hoop hier snel een update te kunnen geven over Sony Vegas Pro benchmark....

[M2M]

Anoniem: 22659 schreef op donderdag 14 januari 2010 @ 11:17:
Hehe, dank je wel voor je toevoeging. Helaas is het niet zo simpel, aangezien het monteren van AVCHD in pinnacle 11 ook goed gaat met een Q6600, maar ook met een AMD Athlon64 X2 5400+. Daarnaast beantwoordt dit niet de vraag over afspelen (vind ik zelf iets interessanter) Plus het zou handig zijn om de test helemaal te standaardiseren. Nu weet iemand met een snelle C2D niet of ie kan monteren in -laten we zeggen- premiere

Ik heb gemonteerd in Premiere. Direct het 1080i materiaal van de camcorder naar premiere gehaald. En er valt met een C2D E8400 op 3.8 - 4.0 GHz niet mee te werken. videofilmpjes vloeiend laten verlopen in de preview ging al helemaal niet.
Toen heb ik ze omgezet naar 720P WMV en dat ging soepeler, maar nog steeds schokkerig. En afspelen in de preview zat er nog steeds niet bij.

Dus of je hebt een zwaarder systeem nodig, of je moet ze eerst even omzetten in een formaat dat minder compressie, en meer diskruimte in beslag neemt.

[kluyze]

Is die preview niet expres schokkerig? Ik ben niet zeker wat je bedoeld maar ik heb (met andere software) al een een film geript van dvd en daar liet die niet elke frame zien in de preview. De preview was wel tijdens het rippen beschikbaar dus mogelijk is dat om de cpu niet te zwaar onnodig te belasten zodat het hoofdprocess (het rippen) niet veel meer tijd in beslag neemt als nodig.

Alleen de preview dus; over het omzetten zelf spreek ik hier niet.

[ Voor 8% gewijzigd door kluyze op 19-01-2010 08:57 ]

[Anoniem: 22659]

Of het ligt aan je codec? Of het ligt aan premiere? Of......

Je raakt precies het doel van dit topic. Op een eenduidige wijze komen tot een manier om vast te stellen of het gaat werken of niet

[antiekeradio]

Dat het afspelen niet goed loopt klopt eigenlijk niet.

heb je een media player die de hardware decoderings functionaliteit van je videokaart kan gebruiken?
(DXVA, of hoe het dan ook mag heten)

normaal afspelen van 1080i media (ook in het voorbeeldvenster van een video editor) zou je met een C2D en een videokaart die hardwarematig AVCHD kan decoden makkelijk moeten kunnen trekken.


Benchmarks met niet kloppende systeeminstellingen hebben geen nut, lijkt me.


Voeg eens wat effecten, en achtergrondmuziek toe (zodat de software ook echt iets aan de stream moet knutselen) en kijk eens of het renderen te doen is?


Ik kwam er na mijn vorige bericht trouwens achter dat in Cyberlink Power Director 8 wel degelijk hardwarematige versnelling van transcoderen gebruikt kan worden. In versie 7 was dat nog niet zo, en dit scheelt echt een slok op een borrel als je een aardige videokaart hebt.

M2M schreef op maandag 18 januari 2010 @ 23:45:
[...]


Ik heb gemonteerd in Premiere. Direct het 1080i materiaal van de camcorder naar premiere gehaald. En er valt met een C2D E8400 op 3.8 - 4.0 GHz niet mee te werken. videofilmpjes vloeiend laten verlopen in de preview ging al helemaal niet.
Toen heb ik ze omgezet naar 720P WMV en dat ging soepeler, maar nog steeds schokkerig. En afspelen in de preview zat er nog steeds niet bij.

Dus of je hebt een zwaarder systeem nodig, of je moet ze eerst even omzetten in een formaat dat minder compressie, en meer diskruimte in beslag neemt.

[M2M]

antiekeradio schreef op dinsdag 19 januari 2010 @ 23:52:
Dat het afspelen niet goed loopt klopt eigenlijk niet.

heb je een media player die de hardware decoderings functionaliteit van je videokaart kan gebruiken?
(DXVA, of hoe het dan ook mag heten)

normaal afspelen van 1080i media (ook in het voorbeeldvenster van een video editor) zou je met een C2D en een videokaart die hardwarematig AVCHD kan decoden makkelijk moeten kunnen trekken.


Benchmarks met niet kloppende systeeminstellingen hebben geen nut, lijkt me.


Voeg eens wat effecten, en achtergrondmuziek toe (zodat de software ook echt iets aan de stream moet knutselen) en kijk eens of het renderen te doen is?


Ik kwam er na mijn vorige bericht trouwens achter dat in Cyberlink Power Director 8 wel degelijk hardwarematige versnelling van transcoderen gebruikt kan worden. In versie 7 was dat nog niet zo, en dit scheelt echt een slok op een borrel als je een aardige videokaart hebt.


[...]

uiteraard moet mijn systeem dit makkelijk kunnen trekken. Als Adobe premiere (CS 4, haalii media splitter en FFDshow voor H264 decodering, wat als ik me goed herinner gebruikt wordt) ook iets meer kan dan enkel softwarefilters gebruiken. Nu heb ik er eerlijk gezegd ook niet zo heel hard naar gezocht, om te kijken of ik de GPU ook in het verhaaltje kon betrekken (GTX260). Dat zou dan wel gescheeld hebben. Hoewel, filters en andere vage dingen worden natuurlijk dan niet via de GPU berekend. Dus als je ook maar een fade toepast, dan moet het ding al over cpu, de videofile decoderen. (of door de gpu decoderen en dan nog eens een filter over het resultaat trekken).

Maar voor mijn gevoel was het premiere dat echt alles softwarematig oplost. De karige opties die in het programma zaten, kon ik toen ook niet veel vinden over GPU acceleratie.

[antiekeradio]

Daaruit blijkt dus maar weer dat de PC hardware ook lang niet alles zegt over de vraag 'is het te doen, of niet'...

ik zal met de pc uit mijn sig een vergelijkend testje doen met Power Director 8.
(met en zonder HW acceleratie)

toen ik versie 7 gebruikte (dus zonder HW acceleratie) kon ik iig goed merken dat het een zware rekenklus was. ik verwacht dat de test in 8 met HW.acc ongeveer op 0,5x realtime snelheid gaat.

[antiekeradio]

antiekeradio schreef op woensdag 20 januari 2010 @ 00:08:
ik zal met de pc uit mijn sig een vergelijkend testje doen met Power Director 8.
(met en zonder HW acceleratie)

OK dat was snel gepiept.

Ik heb een clip van mijn eigen camcorder (Panasonic SD9) genomen, op 1080p geschoten.

De lengte is 47 seconden en 13 frames. (dus net iets meer dan 47,5 seconde)
Hierop heb ik in PowerDirector 8:

- een beeldeffect toegevoegd over de volle lengte van de clip
- een audiotrack onder gezet (in case you wonder: "on the road again" van Canned Heat). ook volle lengte.

dit gerenderd naar 1080i AVCHD:

met Hardware acceleratie duurde dit 1 minuut 6 seconden. Dat was dus beter dan voorspeld.
zonder Hardware acceleratie duurde het 2 minuut 18 seconden. auw!

De tijd zonder HW.acc is ongeveer de snelheid die je kunt vergelijken tussen PC's onderling, puur op basis van de processor prestaties. Een naar 4 GHz overgeklokte C2D heeft ongeveer 75% van de rauwe rekenkracht van mijn Q9550 op stock snelheid, dus dan kun je ongeveer uitdokteren dat een vergelijkbare renderklus bij jou rond de 3 minuut 4 seconden zou komen.

De GTX260 is natuurlijk nog een stuk sneller dan mijn 9800GT, dus ik vermoed dat bij jouw PC het te behalen voordeel van HW.acc nog een heeeel stuk groter is dan bij mij.

edit; voor de duidelijkheid, het systeem waar ik mee vergelijk is dus dat van M2M!

[ Voor 3% gewijzigd door antiekeradio op 20-01-2010 00:29 ]

[antiekeradio]

een interessante contstatering is overigens dat het door de CPU gerenderde filmpje iets kleiner geworden is dan het met HW.acc gerenderde bestand.

bronbestand; 71,8 MB

output file via CPU: 89,9 MB
output file via HW.acc: 100 MB

kwaliteitsverschil is naar mijn idee overigens niet te zien.

[Anoniem: 22659]

Anoniem: 22659 schreef op maandag 18 januari 2010 @ 17:30:

Ik heb inmiddels een mail verstuurd naar de boys van de benchmarks, dus hoop hier snel een update te kunnen geven over Sony Vegas Pro benchmark....

Inmiddels antwoord gehad van de FP crew. De Vegas bench van de FP werkt met een eigen filmbestand met een vaste set filters en overgangen. Nadeel is dat de resolutie veel lager ligt en dat de bitrate nogeens veel lager ligt. Imo is dat dan ook geen optie voor het vraagstuk dat hier ligt.

Ik ga denk ik maar eens op zoek naar een stukje licentievrije 24 mbit/s AVCHD opname om door gebruikers mishandeld te worden. Daarna gaan we maar eens een set filters verzinnen en een test in elkaar draaien.

[M2M]

Anoniem: 22659 schreef op vrijdag 22 januari 2010 @ 16:31:
[...]
Ik ga denk ik maar eens op zoek naar een stukje licentievrije 24 mbit/s AVCHD opname om door gebruikers mishandeld te worden. Daarna gaan we maar eens een set filters verzinnen en een test in elkaar draaien.

goed idee

antiekeradio schreef op woensdag 20 januari 2010 @ 00:27:

De GTX260 is natuurlijk nog een stuk sneller dan mijn 9800GT, dus ik vermoed dat bij jouw PC het te behalen voordeel van HW.acc nog een heeeel stuk groter is dan bij mij.

edit; voor de duidelijkheid, het systeem waar ik mee vergelijk is dus dat van M2M!

vergeet niet dat waarschijnlijk het geaccelereerde converteerproces waarschijnlijk ook CPU gelimiteerd is (heb je daar een CPU-usage uitdraai van?). Aangezien kwa beeldverwerking een videokaart wel 100 keer sneller kan zijn dan een processor.

[sloth]

Anoniem: 22659 schreef op vrijdag 22 januari 2010 @ 16:31:
[...]
Ik ga denk ik maar eens op zoek naar een stukje licentievrije 24 mbit/s AVCHD opname om door gebruikers mishandeld te worden. Daarna gaan we maar eens een set filters verzinnen en een test in elkaar draaien.

Ik schiet zelf filmpjes met een Canon HF100, die doet als ik het goed heb 17Mbps op 1080P. Kan je daar misschien wat mee of is dit nog te licht voor deze test?

[Anoniem: 22659]

sloth schreef op zaterdag 23 januari 2010 @ 12:32:

Ik schiet zelf filmpjes met een Canon HF100, die doet als ik het goed heb 17Mbps op 1080P. Kan je daar misschien wat mee of is dit nog te licht voor deze test?

Zie mijn sig en lees dan mijn vorige opmerking nog een keer

De zoektocht begin ik overigens pas na het weekend. Nu een beetje druk met relaxen

[sloth]

offtopic:
* sloth moet echt eens beter leren lezen

Prima, dan kijken we na het weekend wel weer

[Anoniem: 344238]

Hallo allemaal,

Ben nieuw op dit forum, en heb met aandacht dit topic gevolgt.
Mede omdat ik een verwend video montage hobbyist ben.
Ik werk sinds een aantal maanden met AVCHD full had materiaal en heb hievoor speciaal de hardware aangeschaft.Ik doe al ruim 10 jaar aan videobewerking.

Ik heb de discussie over welke opties kwa hardware mogelijk zijn om de beste en snelste resultaten te bereiken met aandacht gevolgt.

Allereerst zal je je de vraag moeten stellen waarom je gaat werken met AVCHD met een resolutie 1920x1080.
En dan bedoel ik gewoon de praktische kant van het verhaal.
Ik als video maker zegt dan, om een zo hoog mogelijke kwaliteit ( full HD ) te waarborgen.

Ik lees hier dat men materiaal encodeerd naar bv Divx wat een hopeloos langzame bitrate heeft en dus de kwaliteit van Full HD niet eens benaderd.
Indien dit de bedoeling is kan men beter een DV camera of bestanden in DV format nemen, dit bespaart je een hoop geld kwa aanschaf van een camera. Tevens kan iedere Pentium 4 pc met 2GB RAM dit formaat aan om af te spelen en te bewerken.
Indien je toch AVCHD gaat uitvoeren naar bv Divx kun je voordat je het geheel gaat bewerken van te voren omzetten naar AVI of MPEG2. Hier kunnen de meeste pc's makkelijk mee overweg als het om bewerken gaat.

Het grootste probleem is om de kwalitiet van het bron materiaal zoveel mogelijk te waarborgen, dus omzetten naar een lagere resolutie en bitrate is dan al uit ten boze.

Dus waar zit dan de bottleneck als je een systeem gaat samenstellen?
Dit is het hoofdstuk afspelen en bewerken. Door de compressie methode van het AVCHD heeft een doorsnee pc grote problemen dit te bolwerken.
Ook is de gebruikte codec in dit verhaal erg belangrijk en bepaald meteen ook of een stukje software goed redelijk of slecht functioneerd icm de gebruikte hardware.

Dus als de eis is dat je uitvoerbestand dezelfde kwaliteit moet hebben als je bronmateriaal ( AVCHD ) dan heb je pas een stevige Pc nodig.
Indien je hierin afbreuk gaat doen hoef je niet speciaal een monster pc te hebben. Je hoef dan alleen het AVCHD materiaal om te zetten naar een kwalitatief minder gecomprimeerd bestand. Dit kun je met een redelijke uitgeruste Pentium4 of AMD gebaseerde pc al doen.( kost alleen een beetje tijd.) Het bewerken wordt hierdoor ook een stuk eenvoudiger en sneller.( waardoor extra tijd winst.)
Er zijn hiervoor allerlei softwarematige encoder programma's voor waarvan de beste van Elecard is.

Om AVCHD te bewerken gebruik ik een 64Bits systeem met een stevige i7 Intel CPU met 6Gb aan RAM.
Mijn MOBO is een ASUS Rampage II Extreme speciaal om te overclocken.
Ervaring wijst uit dat de CPU de grootste bottleneck blijft, en met name de kloksnelheid die bij een belasting van 55% tijdens het bewerken op 100% van zijn max. frequentie zit. In dit geval wordt nog geen 50% van mijn RAM benut. Ik heb 2 HD's in het systeem één voor het OS en de ander voor opslag.
Als je het echt goed wil doen heb een derde schijf nodig voor de uitvoer van je projecten.
Dit om al je schijven zoveel mogelijk te ontlasten en dus snelheidswinst te behalen.

Ik heb niet zoveel theorethische kennis als de meesten hier op dit topic maar ik praat vanuit mijn eigen ervaring met de benodigde hardware en het werken met Videomontage software.
Desondanks hoop ik dat mijn input nuttig is in de discussie.

Mt vr gr Martin.

[Mr.C4]

Naar welke lossless bestand zou jij een avchd bestand omzetten?
Hardeschijven kosten tegenwoordig niet zoveel meer, dan werk ik liever met grotere videobestanden ipv een nieuwe dure computer.

Paar jaar geleden zette ik stevig gecomprimeerde bestanden om in lossless huffyuv bestanden om die dan te bewerken zonder dat de bestanden extreem groot worden als ongecomprimeerd.
Ik weet niet of er in de tussentijd iets beters is gekomen maar als iemand dat weet dan zou ik dat graag willen weten.

[Anoniem: 16225]

Anoniem: 344238 schreef op zondag 07 februari 2010 @ 13:57:
Hallo allemaal,

Ben nieuw op dit forum, en heb met aandacht dit topic gevolgt.
Mede omdat ik een verwend video montage hobbyist ben.
Ik werk sinds een aantal maanden met AVCHD full had materiaal en heb hievoor speciaal de hardware aangeschaft.Ik doe al ruim 10 jaar aan videobewerking.

...
Mt vr gr Martin.

Goede samenvatting en goede tip om zaken om te zetten naar ander formaat, alhoewel ik denk dat dat voor de meeste van ons niet opgaat omdat we ten koste van alles kwaliteit willen behouden en bovendien het omzetten naar een ander formaat kost ook tijd.
Nu heb jij een hele snelle PC in hoeverre is AVCHD editten nou werkbaar op jou systeem? Loopt dat lekker vlot of zit je nog steeds een uur te wagen op renderingsresultaten. Ik heb echt een sloom systeem dus ik zou graag een gevoel hebben hoe veel sneller een snel systeem nou eigenlijk is. Ik heb geen verstand van intel procs maar ik neem aan dat je een quadcore hebt? Wat ik ook niet kan volgen waarom die editing software niet jouw volledige 6Gb in beslag neemt (al is het maar tijdens renderen), werkt toch altijd sneller als direct alles op HD bewerken.

[ Voor 8% gewijzigd door Anoniem: 16225 op 09-02-2010 12:01 ]

[Anoniem: 344238]

Anoniem: 16225 schreef op dinsdag 09 februari 2010 @ 11:57:
[...]


Goede samenvatting en goede tip om zaken om te zetten naar ander formaat, alhoewel ik denk dat dat voor de meeste van ons niet opgaat omdat we ten koste van alles kwaliteit willen behouden en bovendien het omzetten naar een ander formaat kost ook tijd.
Nu heb jij een hele snelle PC in hoeverre is AVCHD editten nou werkbaar op jou systeem? Loopt dat lekker vlot of zit je nog steeds een uur te wagen op renderingsresultaten. Ik heb echt een sloom systeem dus ik zou graag een gevoel hebben hoe veel sneller een snel systeem nou eigenlijk is. Ik heb geen verstand van intel procs maar ik neem aan dat je een quadcore hebt? Wat ik ook niet kan volgen waarom die editing software niet jouw volledige 6Gb in beslag neemt (al is het maar tijdens renderen), werkt toch altijd sneller als direct alles op HD bewerken.

Ik heb inderdaad een Quadcore 64Bits systeem om AVCHD te bewerken. Hoe snel het bewerken gaat is afhankelijk van het soort bewerking dat uitgevoerd wordt.
Als je bv AVCHD materiaal gaat bewerken met allerlei complexe filters en special FX, dan moet je zelfs met een rap Quadcore systeem rekenen op lange ( preview )rendertijden.
Kwa rendertijden is het vergelijkbaar met een snel Pentium 4 systeem waarmee je standaard DV bewerkt.
Waarom mijn 64Bits systeem niet mijn volle 6GB in beslag neemt, is uiteindelijk te wijten aan de software die ik gebruik.
Na wat tests kwam ik hier achter. er zijn nog maar heel weinig videobewerkingssoftware pakketten die momenteel 64Bits volledig benutten.
Bijna alle moderne pakketten worden door Vista / Windows 7 64Bits ondersteund, maar werken gewoon als 32Bits programma's .
Ik heb uit betrouwbare bron vernomen dat bv. het programma Vegas één van de weinige is die momenteel echt 64Bits is.
De verwachting is dat bv. Pinnacle en Adobe in toekomst ook wel zullen komen met hun 64Bits varianten. De rendertijden zullen dan zeker beduidend sneller worden dan dat ze nu zijn.
tot die tijd stel ik mijn volgende RAM upgrade uit.

Mt vr gr Martin

[Anoniem: 344238]

Mr.C4 schreef op maandag 08 februari 2010 @ 16:08:
Naar welke lossless bestand zou jij een avchd bestand omzetten?
Hardeschijven kosten tegenwoordig niet zoveel meer, dan werk ik liever met grotere videobestanden ipv een nieuwe dure computer.

Tja dat is niet zo eenvoudig. hangt er eigenlijk ook van af van wat je uiteindelijke uitvoerbestand wordt na bewerken.
Als je project later naar DVD gebrand wordt zou ik overwegen om voor het bewerken naar een DV ( avi ) bestand te converteren.
Als je doelbestand 1920x1080 moet blijven kun je overwegen om dit om te zetten naar MPEG4 of MPEG2, maar dit zal enigszins altijd gepaard gaan met verlies van kwaliteit.
Je zal er altijd mee moeten leren leven dat iedere omzetting een degradatie van je bronmateriaal is.
De Elecard converter is hiervoor wel de beste keus omdat tests uitgewezen hebben dat deze dit doet met het beste behoud van kwaliteit.
En of je Pc dan wel makkelijker om gaat met deze bestanden is iets wat je zelf in de praktijk zou moet testen.Ik persoonlijk heb hier geen ervaring mee. Ik weet tenslotte ook niet met welk systeem je werkt.
Op andere forums kan ik hierover ook geen concreet antwoord vinden. Waarschijnlijk omdat het werken met AVCHD nog niet helemaal in zwang is bij de meeste video hobbyisten. De profesionels onder de beeldbewerking werken er al langere tijd mee. maar ik weet dat sommige daarvan werken met octacore iMac's met zo'n slordige 32GB RAM. En dan hoef je echt niet meer te converteren naar een ander formaat.
Tevens werken ze met softwarepaketten die voor de gewone man niet te betalen is, en ongetwijfeld wel 64Bits compatible is.
Er wordt door de doorsnee hobbyist nog massaal met DV formaat gewerkt. de camera's kosten bijna niets meer en de hardware om dit te bewerken is goed betaalbaar.

Mijn bronmateriaal is in ieder geval hetzelfde als mijn uitvoer, en die sla ik op een externe HD op.
Dit speel ik dan via een Media player die de H.264 codec ondersteund af op mijn Full HD TV en Dolby Surround set.
Of brand dit met menu structuur op een BlueRay Disc om op een Blue Ray Speler af te spelen.
De mediaplayer is de goedkoopste optie, want de Blue Ray's zijn mij nog een beetje te prijzig.

mt vr gr Martin

[ Voor 17% gewijzigd door Anoniem: 344238 op 10-02-2010 07:13 ]

[M2M]

Misschien is dit een beetje een stom idee, maar is het niet mogelijk om de video te editen in dvd resolutie, en vervolgens tijdens de render stap op te schalen naar 1080P. Simpelweg de originele bestanden reencoden naar dvd resolutie, en vervolgens editen. Vlak voor de renderstap zet je de originele bestanden weer terug en wordt er gerendered op 1080P. Alleen voor still images en bepaalde effecten zit je dus in de knel.

En de uiteindelijke renderstap neemt dan nog steeds een ENORME berg tijd in beslag, maar dat is eigenlijk hardware (CPU snelheid) afhankelijk. In ieder geval kun je je filmpjes dan wel in realtime editen, zonder op previews te hoeven wachten.

[antiekeradio]

M2M schreef op woensdag 10 februari 2010 @ 08:31:
Misschien is dit een beetje een stom idee, maar is het niet mogelijk om de video te editen in dvd resolutie, en vervolgens tijdens de render stap op te schalen naar 1080P. Simpelweg de originele bestanden reencoden naar dvd resolutie, en vervolgens editen. Vlak voor de renderstap zet je de originele bestanden weer terug en wordt er gerendered op 1080P. Alleen voor still images en bepaalde effecten zit je dus in de knel.

En de uiteindelijke renderstap neemt dan nog steeds een ENORME berg tijd in beslag, maar dat is eigenlijk hardware (CPU snelheid) afhankelijk. In ieder geval kun je je filmpjes dan wel in realtime editen, zonder op previews te hoeven wachten.

dat is de methode die veel renderprogramma's (kunnen) gebruiken. het programma wat ik zelf gebruik is ook 32 bits architectuur en is niet het toonbeeld van stabiliteit en professionele mogelijkheden, maar het werkt allemaal best aardig. het gaat om Cyberlink PowerDirector Ultra. Dat is een programma wat je voor minder dan 100 euro kunt kopen, dus valt eigenlijk reuze mee.

wat me na afloop van de rendertest (bovenaan deze pagina) nog ter ore gekomen is, is dat de hardware matige acceleratie niet 100% compatible is met progressive output.
omdat veel camcorders tegenwoordig een vage tussenvorm tussen interlaced en progressive gebruiken (BCAA ofzo) heeft veel rendering software het er moeilijk mee om te bepalen wat nu precies het input signaal is (en blijkt dat ie meestal voor interlaced kiest)

[Anoniem: 16225]

Anoniem: 344238 schreef op woensdag 10 februari 2010 @ 05:37:
[...]


Ik heb inderdaad een Quadcore 64Bits systeem om AVCHD te bewerken. Hoe snel het bewerken gaat is afhankelijk van het soort bewerking dat uitgevoerd wordt.
Als je bv AVCHD materiaal gaat bewerken met allerlei complexe filters en special FX, dan moet je zelfs met een rap Quadcore systeem rekenen op lange ( preview )rendertijden.
Kwa rendertijden is het vergelijkbaar met een snel Pentium 4 systeem waarmee je standaard DV bewerkt.
Waarom mijn 64Bits systeem niet mijn volle 6GB in beslag neemt, is uiteindelijk te wijten aan de software die ik gebruik.
Na wat tests kwam ik hier achter. er zijn nog maar heel weinig videobewerkingssoftware pakketten die momenteel 64Bits volledig benutten.
Bijna alle moderne pakketten worden door Vista / Windows 7 64Bits ondersteund, maar werken gewoon als 32Bits programma's .
Ik heb uit betrouwbare bron vernomen dat bv. het programma Vegas één van de weinige is die momenteel echt 64Bits is.
De verwachting is dat bv. Pinnacle en Adobe in toekomst ook wel zullen komen met hun 64Bits varianten. De rendertijden zullen dan zeker beduidend sneller worden dan dat ze nu zijn.
tot die tijd stel ik mijn volgende RAM upgrade uit.

Mt vr gr Martin

Dat komt dan mooi uit want ik gebruik Sony Vegas.
Zo te horen (ook in je latere reactie), zal een 6 of achtvoudige core pas echt een beetje uitkomst bieden om AVCHD een beetje vlot te bewerken. Ik ga het op een dualcore in ieder geval niet eens meer proberen.

[ Voor 7% gewijzigd door Anoniem: 16225 op 10-02-2010 11:06 ]

[M2M]

wat is tegenwoordig nog de rede om voor interlaced te gaan? het geeft alleen maar problemen als je wil deinterlacen, wat tegenwoordig op nagenoeg elke tv / scherm noodzakelijk is.

of is het soms zo dat een geinterlacede video eigenlijk effectief maar 12.5 fps heeft, ipv 25 van een progressieve video?

[antiekeradio]

M2M schreef op woensdag 10 februari 2010 @ 11:01:
wat is tegenwoordig nog de rede om voor interlaced te gaan? het geeft alleen maar problemen als je wil deinterlacen, wat tegenwoordig op nagenoeg elke tv / scherm noodzakelijk is.

of is het soms zo dat een geinterlacede video eigenlijk effectief maar 12.5 fps heeft, ipv 25 van een progressieve video?

nee dat is onzin. interlaced video kan net zoveel beeldinformatie bevatten als progressive, je hebt bij interlaced namelijk 50 halve beelden ipv 25 hele

bij NTSC-equivalenten is het overigens 30p vs 60i


De reden dat er nog interlaced signalen gebruikt worden is dat het beeld door middel van een snelle en goede interlacing verbeterd kan worden, zodat je vrijwel dezelfde beeldinformatie per plaatje hebt als progressive, terwijl de beeldfrequentie dubbel zo hoog is.
Als je geen of brakke de-interlacing hebt geeft het wel de bekende 'zaagtand' storingen.

Het is een beetje een afweging. De meeste goede TV's hebben ook goede deinterlacing, alleen al omdat het meeste wat via de kabel binnenkomt ook gewoon interlaced is. Dus het probleem speelt zich vooral af bij opnames voor lagere kwaliteit computerscherm weergave (waarbij je nooit weet of er deinterlacing aanwezig is en hoe die werkt)

[M2M]

dus, wat is dan nu nog het nut van 50 FPS interlaced opnemen, om het vervolgens weer te gaan deinterlacen? Iets wat ik vaag genoeg fout heb zien gaan (weave deinterlace, of de hele boel bij elkaar blenden).

Dus enkel en alleen omdat de voetbal er dan rond uit blijft zien bij een trap, ipv uitgestrekte bol? Dat is toch gewoon een kwestie van fatsoenlijke progressieve opname apparatuur gebruiken? (of analoog opnemen, waarbij elke pixel in parallel behandeld wordt en vervolgens elke frame inscannen)

edit: voor wat verder leeswerk voor mensen die niet helemaal op de hoogte zijn van interlaced videomateriaal:
klik

[The_Doman]

M2M schreef op woensdag 10 februari 2010 @ 11:30:
dus, wat is dan nu nog het nut van 50 FPS interlaced opnemen, om het vervolgens weer te gaan deinterlacen? Iets wat ik vaag genoeg fout heb zien gaan (weave deinterlace, of de hele boel bij elkaar blenden).

Dus enkel en alleen omdat de voetbal er dan rond uit blijft zien bij een trap, ipv uitgestrekte bol? Dat is toch gewoon een kwestie van fatsoenlijke progressieve opname apparatuur gebruiken? (of analoog opnemen, waarbij elke pixel in parallel behandeld wordt en vervolgens elke frame inscannen)

Veel (comsumenten) apparatuur kan nog geen 50 FPS progressive opnemen.
Meestal heb je de keuze tussen 25 FPS progressive en 50 FPS interlaced.
50 FPS interlaced geeft bewegingen gewoon beter weer dan 25 FPS progressive.
En materiaal bestemd voor (HD)TV moet je gewoon niet zelf gaan deinterlacen, laat dit over aan het TV/Display apparaat zelf.

Zie ook deze discussie:
Familiefilmpjes: interlaced houden of deinterlacen?

[ Voor 4% gewijzigd door The_Doman op 10-02-2010 14:28 ]

[Anoniem: 344238]

M2M schreef op woensdag 10 februari 2010 @ 08:31:
Misschien is dit een beetje een stom idee, maar is het niet mogelijk om de video te editen in dvd resolutie, en vervolgens tijdens de render stap op te schalen naar 1080P. Simpelweg de originele bestanden reencoden naar dvd resolutie, en vervolgens editen. Vlak voor de renderstap zet je de originele bestanden weer terug en wordt er gerendered op 1080P. Alleen voor still images en bepaalde effecten zit je dus in de knel.

Het bewerken in DVD resolutie ( 720 x 576 ) heeft in dit geval alleen nut om het bestand makkelijker te bewerken.
Maar eigenlijk ga je hier al afbreuk doen aan je bronbestand, want dat heb je dan omgezet naar een lage resolutie en bitrate.
Naderhand upscalen naar 1920x1080 heeft geen nut want je kan een kwalitatief lager bestand niet meer verbeteren.
Ik vergelijk het maar met het rippen van een audio CD naar een Mp3 bestand met een veel lagere bitrate.
Van dit Mp3 bestand kun je later weer naar een audio CD converteren met een hogere bitrate, maar de informatie ( oftewel het aantal nullen en enen ) die je kwijt was na het rippen naar Mp3 krijg je nooit meer terug naar het origineel.
Probeer maar eens een DVD ( Bronbestand ) om te zetten naar Divx ( werkbestand ), en probeer hierna de Divx weer terug te zetten naar DVD.( doelbestand.)
Als je het originele bronbestand dan vergelijkt met het doelbestand zal je wel degelijk het verschil zien geloof me.
Zoals ik al eerder vertelde levert iedere encoderingsbewerking een verlies in kwaliteit op.
Het is en blijft een keuze, je encodeert je bronmateriaal en neemt genoegen met het resultaat, of je doet geen consesies en hangt er een prijskaartje aan voor de benodigde hardware.

Mt vr gr Martin

[Anoniem: 344238]

Anoniem: 16225 schreef op woensdag 10 februari 2010 @ 11:01:
[...]


Dat komt dan mooi uit want ik gebruik Sony Vegas.
Zo te horen (ook in je latere reactie), zal een 6 of achtvoudige core pas echt een beetje uitkomst bieden om AVCHD een beetje vlot te bewerken. Ik ga het op een dualcore in ieder geval niet eens meer proberen.

Met alle respect, maar dat is een beetje kort door de bocht.
Een quadcore 64Bits systeem is ruim voldoende, zeker als de toekomst gebruikte videobewerkings software voor de gewone consument gebruik gaat maken van de 64bits voordelen.
Met de huidige 32Bits programma's gaat het ook prima maar je moet er niet op rekenen dat je in realtime kunt bewerken, en dat doen de professionels wel.
Maar goed die zijn beroepsmatig bezig en tijd is geld. dus dan is de stap om een systeem te kopen van rond de 12000Euro iets minder groot.
Mijn systeem is iets meer dan 2000Euro en dat is meer binnen het budget van de profesionele amateur, maar ik hoef er niet mijn brood mee te verdienen. Het is en blijft een hobby.

Mt vr gr Martin

[M2M]

Anoniem: 344238 schreef op donderdag 11 februari 2010 @ 03:15:
[...]


Het bewerken in DVD resolutie ( 720 x 576 ) heeft in dit geval alleen nut om het bestand makkelijker te bewerken.
Maar eigenlijk ga je hier al afbreuk doen aan je bronbestand, want dat heb je dan omgezet naar een lage resolutie en bitrate.
Naderhand upscalen naar 1920x1080 heeft geen nut want je kan een kwalitatief lager bestand niet meer verbeteren.
Ik vergelijk het maar met het rippen van een audio CD naar een Mp3 bestand met een veel lagere bitrate.
Van dit Mp3 bestand kun je later weer naar een audio CD converteren met een hogere bitrate, maar de informatie ( oftewel het aantal nullen en enen ) die je kwijt was na het rippen naar Mp3 krijg je nooit meer terug naar het origineel.
Probeer maar eens een DVD ( Bronbestand ) om te zetten naar Divx ( werkbestand ), en probeer hierna de Divx weer terug te zetten naar DVD.( doelbestand.)
Als je het originele bronbestand dan vergelijkt met het doelbestand zal je wel degelijk het verschil zien geloof me.
Zoals ik al eerder vertelde levert iedere encoderingsbewerking een verlies in kwaliteit op.
Het is en blijft een keuze, je encodeert je bronmateriaal en neemt genoegen met het resultaat, of je doet geen consesies en hangt er een prijskaartje aan voor de benodigde hardware.

Mt vr gr Martin

dat was niet wat ik bedoelde,
Adobe premiere gebruikt bronbestanden. Ik zet die dingen altijd in dezelfde map bij elkaar.
Wat nu, als je originele 1080P bestanden omzet naar dvd resolutie en de originelen houd. Je hebt dan dus twee mappen, eentje met de 1080P bestanden in formaat x, en eentje met dvd resolutie bestanden in hetzelfde formaat.
Vervolgens ga je in een programma de filmpjes knippen plakken en editen, wat soepel gaat als je de bestandjes met dvd resolutie gebruikt.
En als het geedit af is, vervang je de dvd resolutie bron bestanden, door de 1080P versie. Dan zet je nog even wat instellingen goed in je edit software, dat de output ook 1080P is en laat je je apparaat ratelen voor een 1080P niet geupscaled, 0x gereencode film (nou ja, 1 keer als je de renderstap van het programma in kwestie meeneemt).

Dan kun je dus vrij eenvoudig realtime editen op low res materiaal, waarna je in de laatste stap pas alle low res bronbestanden vervangt door hun high res tegenhangers. En zolang je de naam van de files, en de codec hetzelfde houd zou er niets aan de hand moeten zijn.

[KopjeThee]

Qua CPU geeft deze benchmark ook wel enig inzicht. Het voordeligst lijkt mij om een systeem te bouwen om een goedkope AMD Phenom II X4 955 Black Edition of de 965. Black edition, dus nog iets te overclocken. Het systeem blijft goedkoop door gunstig geprijste AMD moederborden.

Misschien is het leuk om een keer een video edit systeem op te nemen in de best buy guide

[Mr.C4]

Anoniem: 344238 schreef op woensdag 10 februari 2010 @ 06:25:
[...]

Tja dat is niet zo eenvoudig. hangt er eigenlijk ook van af van wat je uiteindelijke uitvoerbestand wordt na bewerken.
Als je project later naar DVD gebrand wordt zou ik overwegen om voor het bewerken naar een DV ( avi ) bestand te converteren.
Als je doelbestand 1920x1080 moet blijven kun je overwegen om dit om te zetten naar MPEG4 of MPEG2, maar dit zal enigszins altijd gepaard gaan met verlies van kwaliteit.

Doelbestand moet natuurlijk gewoon 1920x1080 blijven en het liefst zonder verlies. Maar ik ga dan ook één en ander probere te testen met diverse lossless formaten.

@hierboven

je linkje werkt bij mij niet goed. Volgens mij bedoel je deze: http://www.tomshardware.c...remiere-Pro-CS4,1404.html
Maar daar wordt alleen het encoderings proces opgemeten, dus niet het edit proces wat volgens mij de bedoeling is van deze topic.
En volgens mij kun je tegenwoordig een i5 of i7 quadcore halen. Vooral de i5 is niet veel duurder dan een phenom II X4. Ik ben trouwens wel benieuwd hoe de hexacores gaan presteren, toch wel weer 2 core'tjes erbij.

[ManiacsHouse]

Zit nu een filmpje te monteren op Premiere Pro CS4. AVCHD in HD-formaat. De Aspect Ratio Conversion voor de sequence staat ingesteld om Hardware te gebruiken, maar dan is het niet vooruit te branden. Hoor alleen audio. Als ik het instel op Software loopt het bijna vlekkeloos...

Mmm... Heb het eens op None gezet en dan loopt de preview ook prima. Ik draai op een E8400 met 4GB en 2x 640GB in raid. En eigenlijk speelt mijn pc alles af zonder problemen. Monteren gaat ook redelijk. Soms wat gehapper, maar niet vaak. En dat kan dus ook aan instellingen van Premiere liggen zoals hierboven.

Avid Media Composer 4 helaas nog niet aan de praat kunnen krijgen op Windows 7.

[ Voor 6% gewijzigd door ManiacsHouse op 13-02-2010 21:07 ]

[M2M]

en welke videokaart gebruik je? (en welke filters / decoders gebruik je?)

[ManiacsHouse]

M2M schreef op zaterdag 13 februari 2010 @ 23:26:
en welke videokaart gebruik je? (en welke filters / decoders gebruik je?)

Ati 3850 in CrossFire. Decoders niet noemenswaardig. Wat Premiere standaard gebruikt denk ik.
Ik ben van origine een platte Pal-editor. Geen bijzondere effecten of 3D dingen.
Het hele HD-gebeuren en codec-gedoe is in eerste instantie wat langs me heen gegaan.

[Anoniem: 16225]

Ik lees net http://tweakers.net/nieuw...egtijdig-op-bij-ebay.html dat AMD bezig is met een 12core CPU (release 1e kwartaal 2010), voor ons momenteel natuurlijk nog niet te betalen maar ik denk dat dit onze performance problemen wel zou verhelpen. En zou het editen misschien eens in real-time kunnen gebeuren. Persoonlijk denk ik dat een 6* core wel een hele verbetering zal zijn maar het editen toch niet snel genoeg zal gaan (als ik de AVCHD edit ervaringen van een i7 zo lees ).
Ben benieuwd hoeveel een 12core systeem gaat kosten over +/- 9 maanden (6 maanden na 1e release van de 12core), moederboarden zullen natuurlijk heel duur zijn vanwege de vele pinnen op zo'n 12* core. CPU zal ook wel duur blijven aangezien het meer bedoeld zal zijn voor de enterprise market.
Zou windows 7-64bit zoveel cores ondersteunen ?

[ Voor 14% gewijzigd door Anoniem: 16225 op 18-02-2010 08:18 ]

[kluyze]

Tuurlijk, de 980X wordt door windows door de ht techniek ook gezien als een 12-core. Daar draait windows ook gewoon op. Zelfs XP-x86

[Anoniem: 16225]

kluyze schreef op donderdag 18 februari 2010 @ 08:33:
Tuurlijk, de 980X wordt door windows door de ht techniek ook gezien als een 12-core. Daar draait windows ook gewoon op. Zelfs XP-x86

Ik hoop dat je gelijk hebt, maar ik kan me de discussie nog herinneren dat Windows maar iets van 2 sockets ondersteunde voor normale mensen en dat je voor meer sockets een andere licentie nodig hebt. Nou weet ik wel dat dit maar 1 socket is, maar ergens denk ik dat Microsoft een grens aan het aantal aan te sturen cores zou willen, want als het zo doorgaat zullen ze 96* cores ook moeten ondersteunen en gaan ze een hoop geld verliezen door de multi-core race en krijgen wij als gebruiker "gratis" extra power bij elke verdubbeling van het aantal cores.

[kluyze]

Inderdaad de beperking zit in het aantal cpu's. Een core wordt door windows niet gezien als een aparte fysieke cpu.

Quad Quad core onder windows 7?
uit dat topic:
http://social.technet.mic...f2-4a5b-adcf-42657e667142
http://www.winsupersite.com/win7/win7_skus_compare.asp

[Blaat]

Volgens mij is dit nog niet langs gekomen maar er is een heel handig programma om bijna alle HD en DVD bestanden om te zetten naar AVCHD.

Bewerken kan echter niet. Dat zal je met Adobe etc. moeten doen.

multiAVCHD linkje

Het programma remuxt de bestanden (geen kwaliteitsverlies) naar AVCHD en kan evt ook transcoden als de video niet AVCHD compatibel is. Het progje gebruikt dan x264 en een 1pass turbo geeft al nagenoeg geen verlies. Een film van 720P duurt ongeveer 2 uur om te transcoden en 1080P 3 uur.

Dit alles op een Pentium Dual core E5200 op 3.0GHz en 2gig ram.

Ik zou zeggen probeer het en oordeel zelf.

Edit: Nee ik heb geen aandelen in dit programma .

[ Voor 3% gewijzigd door Blaat op 22-02-2010 10:10 ]

[Exocet]

Dit is wat Hardwareinfo denkt nodig te hebben om videobwerking te doen:
http://www.hardware.info/...ce/bpufbZtiag/viewconfig/

[Anoniem: 344238]

KopjeThee schreef op zaterdag 13 februari 2010 @ 18:06:
Qua CPU geeft deze benchmark ook wel enig inzicht. Het voordeligst lijkt mij om een systeem te bouwen om een goedkope AMD Phenom II X4 955 Black Edition of de 965. Black edition, dus nog iets te overclocken. Het systeem blijft goedkoop door gunstig geprijste AMD moederborden.

Misschien is het leuk om een keer een video edit systeem op te nemen in de best buy guide

Lijkt me best interesant om te zien hoe diverse systemen presteren, maar wat is een goed video edit systeem? Deze vraag wordt niet alleen hier gesteld maar komt oneindig terug in diverse discussies in allerlei forums.
De ervaring is dat als je het goed wilt doen dit volledig afhankelijk is van het software pakket dat je gebruikt.
Met andere woorden waar ga je mee aan de slag: Adobe, vegas, Pinnacle, Ulead, magix, Grassvalley etc. etc
Veel pakketten werken het beste op een Intel CPU platform icm een Nvidia grafische kaart. Voor somige paketten maakt het niet uit AMD, Intel ATI of Nvidia.
Van bv pinnacle is bekend dat deze het beste overweg kan met Intel CPU's icm een Nvidia grafische kaart.
Dit maakt het verhaal niet echt simpeler maar moet wel meegenomen worden, ander ga je appels met peren vergelijken.
Met andere woorden je kan het duurste snelste overclockte AMD systeem met 12GB RAM testen maar als deze niet lekker met het pakket overweg kan zijn de prestaties misschien nog slechter dan een goedkoop systeem met de juiste specificaties.

Als ik iemand zou moeten adviseren stel ik hem de vraag wat voor camera of bronbestand hij heeft.( in het geval van dit topic bv. AVCHD.)
Dan welk video edit pakket hij wil gaan gebruiken.( beginner, gevorderd, of professionel.)
Wat de eisen zijn van de uitvoerkwaliteit. ( simpel op DVD, Mpeg* of BlueRay disc enz enz.)
Wat is zijn of haar zijn budget. ( is het haalbaar of nog even doorsparen.)
En als laatste het samenstellen van het video edit systeem, oftewel de hardware.

Ik ben persoonlijk nog geen Pc winkel tegen gekomen die goed advies kan geven over dit verhaal.
Als je een willekeurige winkel binnen loopt en je begint over video editing, dan zullen ze je in de meeste gevallen meteen het duurste systeem aanbevelen.
Vandaar dat een hoop mensen gaan speuren op internet naar de informatie en ervaringen van andere mensen.
Misschien een tip voor een hoop mensen die ervaringen en expertise van eindgebruikers willen horen of delen, ga naar: http://www.videomontageforum.nl/forum/

Mt vr gr Martin

[Anoniem: 130680]

Om toch even mijn ervaringen te delen voorzover dat interessant is. Ik zelf heb een Canon Legria HF200 en film voornamelijk korte fragmenten van passerende treinen e.d. Deze filmpjes bewerk ik op een systeem met de volgende configuratie.

CPU: Intel core 2 duo E8400
Moederbord ASUS P5Q Deluxe
Videokaart AMD/ATI 4850 512 MB
Geheugen: Kingston Valueram 4 GB
HDD 2 x Samsung spinpoint 350 GB

OS Windows Vista sp.1

Bewerkingssoftware Windowsmoviemaker met plugins om AVCHD te kunnen lezen en bewerken.

Over het algemene resultaat ben ik zeer tevreden, alhoewel ik denk als ik een ander programma zou aanschaffen het resultaat nog mooier zou kunnen zijn. Ook heb ik geen problemen met Full HD beelden te verwerken, ik gebruik hiervoor een converter om zo min mogelijk kwaliteitsverlies te krijgen. Aangezien ik de filmpjes op YT plaats. Wat ik wel in de toekomst wil aanschaffen is SSD, dat kan de bewerkingssnelheid zeker ten goede komen. Maar over het algemeen voor mijn doeleinden kan dit systeem er mee door. En speelt AVCHD bestanden goed af en ook het bewerken gaat goed, hoe dit met opnames gaat van meer als een kwartier durf ik niet te zeggen. Maar voor korte fagmenten van tussen de minuut en 10 minuten hoef je geen killer systeem te hebben. En valt goed te werken met een alround systeem van nu.

Alleen wat ik mij wel afvraag waneer komt microsoft nou eens met ondersteuning voor AVCHD en MTS bestanden op moviemaker en mediaplayer, anno 2010 zou dat geen schande zijn voor de amateur filmer die wat op Youtube in HD wil gooien.

[M2M]

ik vraag me dus echt af of het bewerken van AVCHD, gelimiteerd is door je CPU of je harde schijf. In dat geval zou een SSD (voor het bewerken van AVCHD) geen merkbare invloed hebben, en heb je meer aan een stevige overklok van je processor. Voor algemene systeem performance is een SSD natuurlijk wel aan te raden. Maar dan moet je het natuurlijk wel als OS schijf inzetten.

[Anoniem: 344238]

M2M schreef op zondag 28 februari 2010 @ 23:41:
ik vraag me dus echt af of het bewerken van AVCHD, gelimiteerd is door je CPU of je harde schijf. In dat geval zou een SSD (voor het bewerken van AVCHD) geen merkbare invloed hebben, en heb je meer aan een stevige overklok van je processor. Voor algemene systeem performance is een SSD natuurlijk wel aan te raden. Maar dan moet je het natuurlijk wel als OS schijf inzetten.

Die mensen die een SSD in hun systeem hebben gebruiken hem inderdaad voor hun OS.
Dit levert volgens mij geen schokkkende prestatie winsten op bij het editten en renderen van een video project.
Het inladen van pluginns en andere programma's zal wel sneller gaan.( dus de opstarttijden van programma's.)
Voor mij is dit niet genoeg reden om een SSD aan te schaffen voor een video edit systeem.
Voor de hardcore gamers is het misschien wel interessant.
Ik zou mijn geld liever investeren in een snellere CPU en geheugen.
Tevens blijken er zowel voor als nadelen te zijn bij het gebruik van een SSD.
Ze zijn erg snel als het gaat om lezen en schrijven, maar als er veel en vaak bestaande bestanden verandert of herschreven moeten worden blijkt de SSD hier lastiger mee om te kunnen gaan.
Dus bij het opstarten van je OS, of bij het spelen van games zal je het verschil wel merken.
Maar voor video editing heb ik mijn twijfels over het nut ervan.
Ook heb je bij video editing een aanzienlijke hoeveelheid opslag nodig, en het liefst drie aparte schijven.
Eén voor je OS en video editing programma, de tweede voor je bronmateriaal, en de derde voor je uitvoerbestanden.
Dus alleen al vanwege de prijs is SSD voor mij out of the question.

[ Voor 30% gewijzigd door Anoniem: 344238 op 02-03-2010 03:20 ]

[miles]

Dit stukje tekst hoort in een ander topic. Sorry

[ Voor 131% gewijzigd door miles op 08-03-2010 09:03 ]

[Anoniem: 153384]

Hallo allemaal,

Ik heb een vraag. Ik heb een tijd terug een Panasonic FullHD hybrid camera aangeschaft. Ik hda studio 12 maar die was niet geschikt voore AVCHD content. Daarom studio 14 gekocht. Nu een tijdje bezig met bewerken, maar 1 doffe ellende. Door het project lopen duurt ellen lang, transitions toevoegen duurt lang.
Het renderen gaat vaak fout, ik heb een bestand van 1uur 47 minuten en wil dit op een dual layer branden. ( blu ray soon ) Nu heb ik dit al zo'n 8 keer aangezet, als hij alles doorloopt duurt dit zo'n 8 uur. ( dus....).
Vaak geeft hij halverwege al een error. Het is me een keer gelukt om een Iso te maken en een keer video_ts bestand, maar als ik die wil branden gooit hij hem er uit met een foutmelding als hij naar de tweede laag wil branden. Als ik nu kies film maken en dan schijfimage maken en branden dan is hij ineens in een half uur klaar en komt de dvd eruit maar daar staat dan niets op.

Al een paar keer contact gehad met Avid. Vragen ze op een gegeven moment of ik soms AVCHD bestanden edit. Ik geef aan dat dit zo is, zegt ze dat het dan waarschijnlijk daar aan ligt. Known issue dus.
Terwijl zij de verpakking maken waarop staat dat het geschikt is voor AVCHD en de systeemeisen hiervoor zijn veel lager dan wat mijn computer heeft.
nml.
AMD Phenom 945 quad core
8GB 800Mhz
Asus Geforce GT9600
3x 7200 rom HDD 1x voor video editing

Daar zou het dus niet aan moeten liggen.
Waarschijnlijk aan het feit dat studio 14 niet mijn 64bits windows 7 ultimate ondersteund en dus mijn 8GB geheugen maar voor een kwart benut.

Kan dit kloppen ?

Als ik een 64bits ondersteund editing pakket zou kopen welek is dan het beste:

Ik hoor goede verhalen over Sony Vegas, maar ook over Magix 17 De luxe.

Iemand een idee of tip ?

BVD

[Exocet]

Ik werk ook met AVCHD van een Panasonic HD camera.
Qua monteren voldoen op dit moment Adobe Premiere CS5 (64bit only) , maar ook Canopus Edius is goed mee te werken. Importeren van de bestanden en de preview zel snel, maar ook overgangen toevoegen is geen enkel probleem. Mijn pc is een dual core met 4gb geheugen en windows 7 64 bit, een pc van een paar jaar oud al. Alleen het renderen duurt erg lang bij m'n eerste tests.

[ManiacsHouse]

Ik zit hier op een Q6600 met 6gb geheugen. Simpele Panasonic cam welke AVCHD uitpoept. Maar als ik het in Premiere plaats zit hij altijd te emmeren dat de codec niet klopt. Altijd zo'n balkje op de tijdlijn dat het niet on-the-fly gespeeld word. Tijdens afspelen moet hij renderen. Beeld ziet er soms niet uit. Blokkerig bovenaan. De uiteindelijk render van het eindresultaat is wel weer rete-strak.