Scrolling text over video

[Lethalis]

Beste tweakers,

Voor een nieuw project op mijn werk is het vereist dat ik filmpjes (avi, mpg, mp4, etc) kan afspelen op een resolutie van 1360 x 768, met daarover transparante vlakken met scrolling text.

Dit heb ik bereikt door WPF te gebruiken. Kwestie van een MediaElement, Image met opacity, en een TextBlock dat verplaatst wordt op basis van het CompositionTarget.Rendering event (dit vermindert het effect van dropped frames tov time based animations).

Dit werkt op zich prima, mits:
- Het systeem Vista draait (omdat WPF frame tearing krijgt in Windows XP)
- Het systeem een grafische kaart met dedicated VRAM heeft > 128MB

Helaas is het de bedoeling dat bovenstaand spul op een Eee Box 202 / 204 moet draaien met Windows XP. Door de frame tearing en brakke performance komen we in de problemen. De Eee Box is echter wel in staat de filmpjes vloeiend af te spelen in Windows Media Player, dus het zou moeten kunnen.

Ik ben samen met een collega een hele week bezig geweest met het zoeken naar alternatieven, maar elke keer als we iets vonden, kwamen we tot de conclusie dat het niets werd.

Bijv. de Managed DirectX library voor AudioVideoPlayback speelt niet alle filmpjes af die we willen. Het direct gebruik van DirectShow filters in C++ is voor ons op dit moment te ingewikkeld. Dit project moet binnen 2 weken operationeel zijn en moet veel communiceren met managed assemblies (wij werken voornamelijk met .Net en hebben te weinig C++ ervaring).

Mijn vraag is nu: zijn er goede managed libraries om DirectShow te gebruiken op Windows XP zonder frame tearing, maar dat je alsnog de kans krijgt om de frames te wijzigen (overlays, texts, etc).

Want wij konden ze niet vinden.. het moet ook productiekwaliteit zijn, DirectShow.Net hebben we bijv geen enkele keer echt stabiel aan de praat gekregen. Het is de bedoeling dat de applicatie 24/7 blijft draaien op TV schermen in openbare plekken, en dat de pc zo klein is dat die praktisch achter het scherm geplakt kan worden, etc.

Help!

PS:
Ik heb ook ontdekt dat ik C++ icm .Net kan gebruiken met Visual C++, dus een goed voorbeeld zou in het allerergste geval ook kunnen helpen (aangezien ik wel een beetje C++ ervaring heb, maar totaal geen kaas heb gegeten van DirectX / DirectShow). We konden alleen veel te weinig vinden hierover.. Ik kom niet verder dan het afspelen van de filmpjes (dat lukt wel, vaak met een ActiveMovie venster, maar dan kan ik er niet meer bij om er iets overheen te zetten).

[ Voor 4% gewijzigd door Lethalis op 28-03-2009 11:56 ]

[Gimmeabrake]

Dit is een heel lastig onderwerp. Ben zelf al jaren op zoek naar de ideale video-afspeelmogelijkheid in .Net en ik heb hem eigenlijk nog niet gevonden. Wat het beste aansluit aan jou wensen(ik maak er zelf ook gebruik van ivm VB.Net) is Directshow.Net. Je kunt daar ook een uitgebreide set aan samples vinden, en er is genoeg over te vinden op msdn dus ik denk dat je daarmee wel verder komt.

[Arjan]

Als het niet perse directshow hoeft te zijn kun je kijken naar SDL_ffmpeg. Das een wrapper om ffmpeg heen waarmee je in no-time filmpjes kan afspelen.

Ik heb deze lib geschreven voor het real-time afspelen van video en ben momenteel bezig met een versie die ook non-realtime video data kan afhandelen.

In combinatie met SDL en SDL_ttf kun je hiermee maken wat je wil.

als je vastzit aan DShow, dan moet je dit maar als niet verzonden beschouwen

[ Voor 4% gewijzigd door Arjan op 29-03-2009 21:44 ]

[Sebazzz]

Tearing? Ligt dat niet meer aan het niet gebruiken van Double Buffering.

Als je een WinForms user interface erg vaak update krijg je ook tearing, nou hebben we het hier wel over WPF met een media control maar misschien kan je er wat mee

[Lethalis]

Sebazzz schreef op zondag 29 maart 2009 @ 22:19:
Tearing? Ligt dat niet meer aan het niet gebruiken van Double Buffering.

Als je een WinForms user interface erg vaak update krijg je ook tearing, nou hebben we het hier wel over WPF met een media control maar misschien kan je er wat mee

Voor zover ik dingen kon vinden hierover, ligt het aan het feit dat WPF niet meer in sync is met de vertical blank in Windows XP, omdat dit in Vista en Windows 7 door de Desktop Window Manager geregeld wordt.

[Lethalis]

Arjan schreef op zondag 29 maart 2009 @ 21:42:
Als het niet perse directshow hoeft te zijn kun je kijken naar SDL_ffmpeg. Das een wrapper om ffmpeg heen waarmee je in no-time filmpjes kan afspelen.

Ik heb deze lib geschreven voor het real-time afspelen van video en ben momenteel bezig met een versie die ook non-realtime video data kan afhandelen.

In combinatie met SDL en SDL_ttf kun je hiermee maken wat je wil.

als je vastzit aan DShow, dan moet je dit maar als niet verzonden beschouwen

Dat klinkt leuk, maar hoe eenvoudig zou ik dit bijv in C# kunnen gebruiken?

Ik heb op de site gelezen dat het kan, maar ik zie nergens voorbeelden

[Lethalis]

gerrymeistah schreef op zondag 29 maart 2009 @ 21:33:
Dit is een heel lastig onderwerp. Ben zelf al jaren op zoek naar de ideale video-afspeelmogelijkheid in .Net en ik heb hem eigenlijk nog niet gevonden. Wat het beste aansluit aan jou wensen(ik maak er zelf ook gebruik van ivm VB.Net) is Directshow.Net. Je kunt daar ook een uitgebreide set aan samples vinden, en er is genoeg over te vinden op msdn dus ik denk dat je daarmee wel verder komt.

Gisteren is het ons gelukt om met managed directx en de audiovideoplayback namespace te doen wat we willen (soort van ), maar de audiovideoplayback namespace biedt ons niet genoeg mogelijkheden.

Wel zijn we erachter dat het met managed directx echt veel beter performt dan met wpf en ook perfect draait op windows xp.

Op dit moment heb ik van mijn leidinggevende de opdracht gekregen om voorlopig even door te ontwikkelen in WPF, omdat we iets nodig hebben om te laten zien.. maar ik ben wel erg benieuwd in hoeverre het mogelijk zou zijn om Directshow.net in combinatie met Managed DirectX te gebruiken.

Het idee is in feite dat je dan:
- met 60 frames per seconde een d3ddev.present / drawscene doet, waardoor de tekst vloeiend loopt op 60hz tft schermen
- daarbij altijd de op dat moment beschikbare video frame mee rendert, ook al draait de video niet op 60 frames per seconde, maar bijv op 25 tot 30

Als dat goed zou lukken, zou het erg iig vloeiend uitzien en is ons probleem opgelost.

Met Directshow.net zou ik dan een soort IFrameGrabber moeten gebruiken, toch? Ik ben er alleen niet helemaal uit hoe ik vanuit dat formaat dan overga naar een managed direct texture dat ik kan gebruiken. Mijn idee is dat het hele video gebeuren in een aparte thread draait, en steeds - op een thread safe manier - de huidig beschikbare frame (Texture eigenlijk!) aanlevert, zodat ik die weer kan gebruiken in mijn DrawScene method.

Het blijft alleen een kwestie van aanklooien zonder goede voorbeelden tot nu toe..

Ik heb wel ooit deze gevonden voor het XNA framework:
http://www.codeplex.com/XNADSPlayer

Maar die is erg rot geprogrammeerd. Het begint ermee dat het OnVideoComplete event vanuit de verkeerde thread wordt aangeroepen, maar daar kon ik omheen werken.

Het echte probleem zit hem in de UpdateBuffer method, die een vertaalslag doet van BGR naar RGBA, wat erg veel processor kracht vergt, en daardoor veel te traag is om te gebruiken. Als iemand weet hoe je dit veel beter en sneller kunt doen, zou ik dat geweldig vinden!

Ik weet bijv ook niet of de conversie per se nodig is, maar als ik de BGR data direct toon, dat krijg ik een zwart scherm met wat witte bewegende stipjes

[ Voor 12% gewijzigd door Lethalis op 31-03-2009 09:56 ]

[Arjan]

Lethalis schreef op dinsdag 31 maart 2009 @ 09:25:
[...]

Dat klinkt leuk, maar hoe eenvoudig zou ik dit bijv in C# kunnen gebruiken?

Ik heb op de site gelezen dat het kan, maar ik zie nergens voorbeelden

Ik heb geen ervaring met C#, dus daar kan ik je niet mee helpen
Overigens zou het voor een ervaren C/C++ programeur niet veel tijd mogen kosten om het bijgeleverde example om te bouwen het soort video-kiosk achtige applicatie wat jij nodig hebt.
Voor een beginnend C/C++'er zou het dus ook te doen moeten zijn.

Lethalis schreef op dinsdag 31 maart 2009 @ 09:36:
[...]

Het echte probleem zit hem in de UpdateBuffer method, die een vertaalslag doet van BGR naar RGBA, wat erg veel processor kracht vergt, en daardoor veel te traag is om te gebruiken. Als iemand weet hoe je dit veel beter en sneller kunt doen, zou ik dat geweldig vinden!

Ik weet bijv ook niet of de conversie per se nodig is, maar als ik de BGR data direct toon, dat krijg ik een zwart scherm met wat witte bewegende stipjes

Ik gok dat niet de stap van BGR naar RGBA traag is, maar de stap van YCbCr 420 naar RGB(A).
Er zijn verschillende methoden om dit te versnellen. De meest gebruikte is leunen op de YUV overlay mogelijkheid van videokaarten. Dan hoeft de conversie dus niet op de CPU plaats te vinden. Tegenwoordig wordt er ook vaak gebruik gemaakt van OpenGL/DirectX hardware acceleratie. De conversie van YUV naar RGB wordt dan op de videokaart gedaan. (tijdens pixel transfers, via CUDA, of op de GPU, bv. mbv. shaders)
Als het echt op de CPU moet, dan kun je kijken naar MMX instructies. Dit is ook wat libswscale wat onderdeel is van ffmpeg doet. Deze code is echter GPL gelicenseerd en wellicht niet bruikbaar voor een commercieel project.
SDL_ffmpeg 0.9.0 gebruikt een vrij eenvoudige conversie van YCbCr naar RGBA die ik doormiddel van lookuptables een beetje snelheid heb gegeven. De volgende versie ondersteund ook andere formaten zodat je zelf een optimale conversie kan kiezen

[Lethalis]

Arjan schreef op dinsdag 31 maart 2009 @ 10:58:
[...]

1) Ik heb geen ervaring met C#, dus daar kan ik je niet mee helpen
Overigens zou het voor een ervaren C/C++ programeur niet veel tijd mogen kosten om het bijgeleverde example om te bouwen het soort video-kiosk achtige applicatie wat jij nodig hebt.
Voor een beginnend C/C++'er zou het dus ook te doen moeten zijn.

[...]

2) Ik gok dat niet de stap van BGR naar RGBA traag is, maar de stap van YCbCr 420 naar RGB(A).
Er zijn verschillende methoden om dit te versnellen. De meest gebruikte is leunen op de YUV overlay mogelijkheid van videokaarten. Dan hoeft de conversie dus niet op de CPU plaats te vinden. Tegenwoordig wordt er ook vaak gebruik gemaakt van OpenGL/DirectX hardware acceleratie. De conversie van YUV naar RGB wordt dan op de videokaart gedaan. (tijdens pixel transfers, via CUDA, of op de GPU, bv. mbv. shaders)
Als het echt op de CPU moet, dan kun je kijken naar MMX instructies. Dit is ook wat libswscale wat onderdeel is van ffmpeg doet. Deze code is echter GPL gelicenseerd en wellicht niet bruikbaar voor een commercieel project.
SDL_ffmpeg 0.9.0 gebruikt een vrij eenvoudige conversie van YCbCr naar RGBA die ik doormiddel van lookuptables een beetje snelheid heb gegeven. De volgende versie ondersteund ook andere formaten zodat je zelf een optimale conversie kan kiezen

1) Zelfs als we iets in C++ zouden doen, dan zal er heel veel moeten worden gecommuniceerd met bestaande managed classes die in .Net zijn geschreven. En dat is best ingewikkeld vind ik zelf, omdat je nogal wat conversies van datatypes krijgt.

2) De helft van wat je zegt zal ik moeten googlen om te begrijpen

[drZymo]

Mischien wel helemaal uit de richting, maar is dit - http://www.codeplex.com/DirectDrawOverlayLib - mischien wat?

[Lethalis]

drZymo schreef op dinsdag 31 maart 2009 @ 20:05:
Mischien wel helemaal uit de richting, maar is dit - http://www.codeplex.com/DirectDrawOverlayLib - mischien wat?

Nou ja, mijn hele probleem is om filmpjes ueberhaupt goed af te spelen binnen een DirectDraw surface (ipv ActiveMovie venster). Op het moment dat ik zover ben, kan ik in principe zelf mijn sprites en dingen er op zetten.

Ik zal er hoe dan ook even naar kijken

Maar ik ben erg benieuwd of er hier mensen zijn die een goede manier weten om van een IntPtr buffer (DirectShowNet) tot een Texture (Managed DirectX) of Texture2D (XNA) class te komen. Daarmee zou ik erg geholpen zijn, want dan denk ik dat ik de rest zelf kan oplossen.

[Woy]

Mischien heb je hier iets aan? http://xna-uk.net/blogs/r...n-your-windows-games.aspx

[Lethalis]

Woy schreef op woensdag 01 april 2009 @ 09:07:
Mischien heb je hier iets aan? http://xna-uk.net/blogs/r...n-your-windows-games.aspx

Die doet dezelfde vertaling in VideoPlayer.UpdateBuffer() die hem te traag maakt voor mijn toepassingen (dit moet op een Intel Atom draaien):

code:

/// <summary>
/// Worker to copy the BGR data from the video stream into the RGBA byte array for the Output Frame.
/// </summary>
private void UpdateBuffer()
{
    int waitTime = avgTimePerFrame != 0 ? (int)((float)avgTimePerFrame / 10000) : 20;

    int samplePosRGBA = 0;
    int samplePosRGB24 = 0;

    while (true)
    {
        for (int y = 0, y2 = videoHeight - 1; y < videoHeight; y++, y2--)
        {
            for (int x = 0; x < videoWidth; x++)
            {
                samplePosRGBA = (((y2 * videoWidth) + x) * 4);
                samplePosRGB24 = ((y * videoWidth) + x) * 3;

                videoFrameBytes[samplePosRGBA + 0] = bgrData[samplePosRGB24 + 0];
                videoFrameBytes[samplePosRGBA + 1] = bgrData[samplePosRGB24 + 1];
                videoFrameBytes[samplePosRGBA + 2] = bgrData[samplePosRGB24 + 2];
                videoFrameBytes[samplePosRGBA + 3] = alphaTransparency;
            }
        }

        frameAvailable = false;
        while (!frameAvailable)
        { Thread.Sleep(waitTime); }
    }
}

Dit omdat

code:

// Set video data into the Output Frame
outputFrame.SetData<byte>(videoFrameBytes);

Verwacht dat je met een array van 4*8*x aankomt (32 bits). Ik heb al eens geprobeerd

code:

// Create Output Frame Texture2D with the height and width of the video
outputFrame = new Texture2D(graphicsDevice, videoWidth, videoHeight, 1, TextureUsage.None, SurfaceFormat.Color);

Aan te passen (het SurfaceFormat), maar dan gaat het elke keer mis (exceptions). SurfaceFormat.Bgr24 werkt helaas niet wanneer ik bgrData meteen probeer toe te kennen aan het outputFrame met SetData

[ Voor 80% gewijzigd door Lethalis op 01-04-2009 12:28 ]

[Arjan]

los van het feit dat bovenstaande code best nog wel wat optimalisaties kan gebruiken, kan ik me niet voorstellen dat C# zo retarded is dat ie dit niet heel behoorlijk kan optimaliseren..

weet je zeker dat dit stuk code zo traag is? en over hoeveel tijd hebben we het dan

[Lethalis]

Arjan schreef op woensdag 01 april 2009 @ 12:43:
los van het feit dat bovenstaande code best nog wel wat optimalisaties kan gebruiken, kan ik me niet voorstellen dat C# zo retarded is dat ie dit niet heel behoorlijk kan optimaliseren..

weet je zeker dat dit stuk code zo traag is? en over hoeveel tijd hebben we het dan

Ik heb bovenstaande code op een Atom laten draaien, en ik heb normale DirectShow laten draaien via de AudioVideoPlayback namespace. Daarbij was er een drastisch verschil tussen het aantal frames per seconde.

Bovenstaande code is zo traag dat de filmpjes ueberhaupt niet meer vloeiend draaien, je ziet echt dat de frames per stuk worden getoond.

Ik zie niet echt waar dit verschil anders vandaan moet komen trouwens.. als jij denkt dat het niet hieraan ligt, waaraan dan wel?

De filmpjes die ik afspeel zijn bijvoorbeeld in H264 formaat en als je dan per frame dit gaat omzetten op een Atom dan schiet het niet op.

[Arjan]

Lethalis schreef op woensdag 01 april 2009 @ 13:28:
[...]

Ik heb bovenstaande code op een Atom laten draaien, en ik heb normale DirectShow laten draaien via de AudioVideoPlayback namespace. Daarbij was er een drastisch verschil tussen het aantal frames per seconde.

[...]

Dit komt waarschijnlijk doordat er geen conversie plaatsvind indien je standaard DirectShow gebruikt. De film wordt dan direct naar een YUV overlay gezet, inplaats van de omzetting naar RGB, zoals ik ook al eerder opmerkte.

Zodra je bewerkingen wil doen op video materiaal doe je dit bijna altijd op RGB data, al is het strikt genomen niet noodzakelijk

[Woy]

De conversie naar RGB data zou je natuurlijk gewoon in een Pixel Shader kunnen doen als dat echt het probleem is. Wat Arjan trouwens af voorgesteld had.

[ Voor 14% gewijzigd door Woy op 01-04-2009 14:41 ]

[Matis]

Arjan schreef op woensdag 01 april 2009 @ 14:06:
[...]
Zodra je bewerkingen wil doen op video materiaal doe je dit bijna altijd op RGB data, al is het strikt genomen niet noodzakelijk

Pardon Ik zit zelf in de broadcast branche en we werken nooit met RGB. YUV is dé standaard en laat zich veel gemakkelijker bewerken dan RGB.

Wat betreft die PixelShader, ik weet niet wat voor een GPU in de Eee box zit, maar als hij het hardware matig ondersteund dan is het mooi meegenomen en idd snel om te doen!

Edit:
In OpenGL zal ik niet gaan werken met YUV, maar een RGB(A) aanbieden. Weet niet hoe DX daarmee omgaat maar als ik OpenGL YUV frames aanlever, dan krijg ik 2 FPS. Dezelfde RGB(A) frames moet ik cappen op 60 FPS

Edit 2:
Ik heb zelf betrekkelijk veel kennis opgedaan in CUDA de afgelopen maanden. Weet niet of er een Nvidia 8, 9 of 200 serie inzit, maar anders kun je je GPU ook parallel laten rekenen.

[ Voor 26% gewijzigd door Matis op 01-04-2009 14:58 ]

[Skinkie]

toaomatis schreef op woensdag 01 april 2009 @ 14:53:
[...]


Pardon Ik zit zelf in de broadcast branche en we werken nooit met RGB. YUV is dé standaard en laat zich veel gemakkelijker bewerken dan RGB.

Wat betreft die PixelShader, ik weet niet wat voor een GPU in de Eee box zit, maar als hij het hardware matig ondersteund dan is het mooi meegenomen en idd snel om te doen!

Edit:
In OpenGL zal ik niet gaan werken met YUV, maar een RGB(A) aanbieden. Weet niet hoe DX daarmee omgaat maar als ik OpenG: YUV frames aanlever, dan krijg ik 2 FPS. Dezelfde RGB(A) frames moet ik cappen op 60 FPS

Is het zo moeilijk om een transparente plane te maken in DirectX met video op een plane er achter? Op vsync verschuiven...

[Matis]

Skinkie schreef op woensdag 01 april 2009 @ 14:57:
Is het zo moeilijk om een transparente plane te maken in DirectX met video op een plane er achter? Op vsync verschuiven...

In het land der blinden is de eenoog koning...

Voor jou is het misschien gesneden koek, maar voor de TS zeker niet. Daarnaast is het de bedoeling dat de TS er wat van leert en we proberen hem de goede weg op te sturen. Daarnaast moet zijn code zo lightweight zijn dat het op een atom gedraaid kan worden.

[ Voor 8% gewijzigd door Matis op 01-04-2009 15:02 ]

[Lethalis]

Woy schreef op woensdag 01 april 2009 @ 14:40:
De conversie naar RGB data zou je natuurlijk gewoon in een Pixel Shader kunnen doen als dat echt het probleem is. Wat Arjan trouwens af voorgesteld had.

En hoe zou je dat dan doen? (en ja, ik heb al google gebruikt, maar vond niet zoveel qua conversie)

Wat voorbeeldcode zou mooi zijn

[ Voor 9% gewijzigd door Lethalis op 01-04-2009 15:32 ]

[Matis]

C++:

//RGB to YUV Conversion
    Y  =      (0.257 * R) + (0.504 * G) + (0.098 * B) + 16
    Cr = V =  (0.439 * R) - (0.368 * G) - (0.071 * B) + 128
    Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128
//YUV to RGB Conversion
    B = 1.164(Y - 16)                   + 2.018(U - 128)
    G = 1.164(Y - 16) - 0.813(V - 128) - 0.391(U - 128)
    R = 1.164(Y - 16) + 1.596(V - 128)

Bron: http://www.fourcc.org/fccyvrgb.php

Verder zou je je eens kunnen verdiepen in CUDA. Wat ik doe is een frame naar de GPU kopieren; Daar voor elk pixel de RGB waardes maken en dan het nieuwe frame weer terug kopiëren naar mn RAM.

Misschien kan DX het zelfs direct vanaf je GPU geheugen vissen en weergeven op je scherm

[Arjan]

toaomatis schreef op woensdag 01 april 2009 @ 14:53:
[...]


Pardon Ik zit zelf in de broadcast branche en we werken nooit met RGB. YUV is dé standaard en laat zich veel gemakkelijker bewerken dan RGB.

conculega

YUV data is makkelijker te comprimeren, en heeft (traditioneel) aanzienlijk wat voordelen ten opzichte van RGB, maar bewerkingen in het computer domein zijn handiger op RGBA data.

toaomatis schreef op woensdag 01 april 2009 @ 16:00:

[...]

Verder zou je je eens kunnen verdiepen in CUDA. Wat ik doe is een frame naar de GPU kopieren; Daar voor elk pixel de RGB waardes maken en dan het nieuwe frame weer terug kopiëren naar mn RAM.

Misschien kan DX het zelfs direct vanaf je GPU geheugen vissen en weergeven op je scherm

Afhankelijk van je doel kun je de bewerkingen beter op de GPU blijven doen. Elke actie die de data weer terug naar het ram moet kopieren zal het geheel vertragen..

DX heeft verder geen magische connectie met de hardware en zal net als openGL enkele 'dure' calls moeten maken om data van/naar de GPU/CPU te transporteren.

[Matis]

Die vertraging valt opzich wel mee. Die is net zo snel als je PCI-e bus. Normaliter 3 Gbps. Een HD frame van 3 mb duurt dus 1 ms. Uploaden naar je GPU gaat meestal nog iets sneller

Anyway. Ik stel de TS voor om eerst eens ff het algoritme werkend te krijgen en daarna pas te gaan optimaliseren en eventueel hardwarematige versnelling toe te passen om dit op te lossen!

[Lethalis]

toaomatis schreef op woensdag 01 april 2009 @ 17:35:
Anyway. Ik stel de TS voor om eerst eens ff het algoritme werkend te krijgen en daarna pas te gaan optimaliseren en eventueel hardwarematige versnelling toe te passen om dit op te lossen!

We hebben al een XnaTest projectje, dat gebruik maakt van de player die op http://www.codeplex.com/XNADSPlayer staat. Hetzij in een iets aangepaste vorm, zodat de boel ook goed met repeat etc werkt.

Ik zit dus vooral met het optimaliseren ervan. Want zonder die optimalisatie is de hele techniek niet bruikbaar..

[Matis]

Lethalis schreef op donderdag 02 april 2009 @ 08:37:
[...]
Ik zit dus vooral met het optimaliseren ervan. Want zonder die optimalisatie is de hele techniek niet bruikbaar..

Heb je een 8xxx 9xxx of 200 serie videokaart van NVidia in je pc zitten? Zoja, dan zal je met CUDA aan de gang kunnen om parallelle reken taken te laten doen door je videokaart.

Je zou er ook een pixelshader voor kunnen schrijven zoals hierboven genoemd, dat is wat lastiger, maar dan regelt je OS het hele hardwarematige versnellen van de calculaties. (Ati en NVidia)

[Lethalis]

toaomatis schreef op donderdag 02 april 2009 @ 08:42:
[...]
Heb je een 8xxx 9xxx of 200 serie videokaart van NVidia in je pc zitten? Zoja, dan zal je met CUDA aan de gang kunnen om parallelle reken taken te laten doen door je videokaart.

Nee. Sterker nog, ik heb nog niet eens een aparte video kaart

Ik heb hier een Intel G965 Express chipset onboard Maar een wel Core 2 duo met 4GB RAM

En het moet bij mij werken, en op een EeeBox B204, die heeft een ATI Radeon HD3450 met 256MB dedicated VRAM met een Atom cpu plus 2GB RAM.

Het gaat dus om low end hardware (relatief gezien).

Microsoft haalt in hun Video class (AudioVideoPlayback namespace) iets uit waardoor het wel goed werkt, de grote vraag voor mij is alleen wat ze daar doen zodat ik hetzelfde kan doen, hetzij met wat meer controle erover. De vraag blijft hoe je van een DirectShow frame (IntPtr) zo snel mogelijk naar een Texture object gaat, dat is eigenlijk het enige wat ik wil weten, want de rest kan ik dan zelf invullen.

[Woy]

Lethalis schreef op donderdag 02 april 2009 @ 08:48:
[...]
Nee. Sterker nog, ik heb nog niet eens een aparte video kaart

Ik heb hier een Intel G965 Express chipset onboard Maar een wel Core 2 duo met 4GB RAM

En het moet bij mij werken, en op een EeeBox B204, die heeft een ATI Radeon HD3450 met 256MB dedicated VRAM met een Atom cpu plus 2GB RAM.

Het gaat dus om low end hardware (relatief gezien).

Microsoft haalt in hun Video class (AudioVideoPlayback namespace) iets uit waardoor het wel goed werkt, de grote vraag voor mij is alleen wat ze daar doen zodat ik hetzelfde kan doen, hetzij met wat meer controle erover. De vraag blijft hoe je van een DirectShow frame (IntPtr) zo snel mogelijk naar een Texture object gaat, dat is eigenlijk het enige wat ik wil weten, want de rest kan ik dan zelf invullen.

Volgens tweakers heeft de G965 shader model 2 dus dan kan je daar iets mee doen
nieuws: Intel geeft G965-chipset Shader Model 2.0 ondersteuning

Dus dan zou je iets kunnen doen met je pixel shader. Zeker bij de EeeBox zou dat verschil moeten maken aangezien die een veel langzamere processor heeft maar wel een redelijke videokaart.

[Matis]

Woy schreef op donderdag 02 april 2009 @ 08:55:
Volgens tweakers heeft de G965 shader model 2 dus dan kan je daar iets mee doen

My thoughts exactly

Ik heb ooit een keer voor een vriend de algoritmes geschreven;

http://www.gamedev.net/columns/hardcore/dxshader1/ dat is een mooie duidelijke site

Dit is de guideline volgens MS: http://msdn.microsoft.com/en-us/library/bb509635(VS.85).aspx

[ Voor 11% gewijzigd door Matis op 02-04-2009 09:11 ]

[Woy]

toaomatis schreef op donderdag 02 april 2009 @ 09:09:
[...]


My thoughts exactly

Ik heb ooit een keer voor een vriend de algoritmes geschreven;

http://www.gamedev.net/columns/hardcore/dxshader1/ dat is een mooie duidelijke site

Dit is de guideline volgens MS: http://msdn.microsoft.com/en-us/library/bb509635(VS.85).aspx

Ik zou eerder even hier: http://www.riemers.net/eng/Tutorials/XNA/Csharp/series3.php kijken. Dit gaat over HLSL in XNA, en is een eenvoudige tutorial, waar de TS wel genoeg aan zou moeten hebben.

Maar ik denk ook dat het belangrijk is dat hij eerst goed gaat profilen, om de bottlenecks te bepalen, en kijkt welke gedeeltes je daarvan eenvoudig op de GPU kunt doen.

[alienfruit]

Aah, ik heb voor zoiets vergelijkbaars openframework gebruikt. Erg makkelijk toe te passen. Maar goed, niet echt iets wat je zoek omdat je werkt in C#. Leuk mij wel interessant om het te benoemen.