C++

Scrivere un render custom per il Video in WPF

Gianluca Carucci — Fri, 25 Jan 2008 09:52:27 GMT

Partiamo dal problema. Il controllo MediaElement (così come il controllo MediaPlayer e DrawingVideo) ha il grosso limite di utilizzare come sorgente video solo una sorgente conosciuta proveniente da un Uri. Per conosciuta si intende una sorgente, il cui protocol handler è registrato nel sistema (client).

Come faccio a riprodurre un flusso video proveniente da una sorgente custom (scheda di acquisizione video, piuttosto che un protocollo di streaming custom) e/o codificato con un codec proprietario?

Cristian, in questo articolo, spiega chiaramente il problema e propone un paio di soluzioni basate su l'interoperabilità tra Win32/WinForm e WPF la prima e la registrazione nel sistema di un custom protocol handler la seconda.

La prima soluzione ha il vantaggio di non richiedere la registrazione di nulla sul sistema client; ha però il grosso svantaggio di non supportare trasformazioni sulla finestra video. I vantaggi e gli svantaggi si ribaltano nella seconda opzione.

Questo post mostra una soluzione brillante che promette di sorpassare entrambi i vincoli.

Per farla breve: questa soluzione utilizza le API WIC per accedere direttamente al buffer unmanaged utilizzato dall'oggetto BitmapSource. Sarebbe già abbastanza per fare buone cose con un po' di Interop e la libreria DirectShowLib.

Per gli intrepidi - coloro che non rabbrividiscono davanti alla necessità di scrivere codice C++ e usare COM - è possibile scrivere un filtro di render in DirectShow, che accetta un riferimento al buffer utilizzato dalla BitmapSource. E' quindi possibile costruire un grafo DirectShow la cui destinazione video è proprio il buffer della BitmapSource esposto a COM dal nostro render. Siamo riusciti a combinare la versatilità di DirectShow con la potenza di WPF. Ma tutto questo - forse - è un'altra storia.

Technorati Tag: DirectShow,WPF,MediaPlayer

Pensate come sarebbe brutto C# se...

Gianluca Carucci — Tue, 30 Oct 2007 14:11:39 GMT

il compilatore restituisse un errore nel caso in cui non gli piaccia l'ordine dei namespace dichiarati a inizio file.

Oppure se...

il compilatore restituisse un errore nel caso in cui non gli piaccia l'ordine delle classi/delegati/enumerazioni all'interno di un file.

O ancora peggio se...

il compilatore restituisse un errore nel caso in cui non gli piaccia l'ordine dei file da compilare.

Ma anche se...

con tanta fatica (e fortuna) riusciamo a trovare la giusta combinazione, ma un piccolo flag - fondamentale per la buona riuscita della compilazione - all'interno della configurazione del nostro progetto, provoca un errore di linking.

Per fortuna non sono problemi che si riscontrano in C#, ma aimè sono situazioni frequenti in progetti C++; ancor più frequenti quando si cerca di compilare un software Open Source. Ci fosse una volta che si scarica un progetto C++, si lancia la compilazione e questa funziona 'al primo colpo': certo, spesso il problema è dovuto ad una cattiva organizzazione del codice (e delle librerie), ma il linguaggio certo non aiuta.

Sia chiaro, non odio C++, mi piace e per certi versi lo amo (diciamo che lo stimo moltissimo); come potrei odiare un linguaggio che procaccia il cibo al mio caro fratellino ed evita che sia io a doverlo mantenere?

Quello che però proprio non riesco a mandare giù è dover perdere del tempo (in alcuni casi ore o giorni), a risolvere dei problemi completamente estranei al reale scopo della soluzione che sto sviluppando. Se c'è un pregio di C# - e .NET in generale - è proprio questo: lo sviluppo è concentrato per lo più verso l'aspetto funzionale, invece di quello tecnologico e infrastrutturale.

Se avete la necessità di dover compilare con MSVC++ 2005 l'ultima versione della libreria xvid è il vostro giorno fortunato: questa sera impiegherete 4 ore a decidere come vestirvi per andare sui navigli o al Karement piuttosto che perderle per capire come risolvere questo errore (ovviamente, lo stesso identico progetto compila correttamente usando MSVC++ 2003):

error C2632: 'int' followed by 'int' is illegal

Il problema è causato dal punto del codice in cui è incluso windows.h nel file portab.h. Spostando l'inclusione del file all'inizio del sorgente tutto funzionerà magicamente.

Per essere un po' più puliti sostituiamo la dichiarazione di inclusione (nel punto originale) con il seguente codice:

#if defined(_MSC_VER) && _MSC_VER < 1400

#include <windows.h>

#endif

ed aggiungiamo all'inizio del file il codice:

#if defined(_MSC_VER) && _MSC_VER == 1400

#include <windows.h>

#endif

In questo modo se il compilatore Visual C++ 2005, l'inclusione del file sarà spostata all'inizio del sorgente, altrimenti sarà lasciata dov'è.

Technorati Tag: C++ , C# , include , compilazione , xvid , vs2005

Nuovo ma già obsoleto?!?!?

Gianluca Carucci — Thu, 31 Aug 2006 08:07:00 GMT

Ogni tanto, leggendo l'msdn, escono cose simpatiche:)

Tratto dalla documentazione del metodo CppCodeProvider.CreateCompiler su MSDN Library:

.NET Framework Class Library

CppCodeProvider.CreateCompiler Method

Note: This method is new in the .NET Framework version 2.0.

NOTE: This method is now obsolete.

Creates an instance of the C++ code compiler.

Namespace: Microsoft.VisualC
Assembly: CppCodeProvider (in cppcodeprovider.dll)

Non bastasse, l'implementazione del metodo restituisce un NotImplementedException....

Technorati tags: Msdn, Codedom

Media Foundation: DirectShow avrà un successore?

Gianluca Carucci — Wed, 09 Aug 2006 10:31:00 GMT

Finalmente oltre a un nuovo motore grafico (WPF), un nuovo motore di Workflow (WWF) e un nuovo layer di comunicazione (WCF), Vista ha anche un nuovo motore per applicazioni multimediali chiamato Media Foundation (che fantasia).

L'obbiettivo è quello di offrire una piattaforma capace di supportare pienamente l'alta definizione e di permettere una adeguata protezione dei contenuti multimediali manipolati.

Nonostante DirectShow sia una piattaforma molto versatile, comincia a risentire della sua decennale età. Media Foundation promette di introdurre una architettura più accessibile e soprattutto più in linea con i progressi fatti negli ultimi anni nel campo del multimedia.

Se vi aspettate che Media Foundation si basi su tecnologia managed rimarrete delusi (e non sarete gli unici:P). Direttamente dall'SDK:

"Media Foundation requires Windows Vista. Media Foundation uses the component object model (COM) and requires C/C++. There is no managed layer for Media Foundation at this time."

Technorati Tags: MediaFoundation, DirectShow

Region in C++/CLI

Gianluca Carucci — Sun, 29 Jan 2006 08:52:00 GMT

Tutti ormai sanno che la direttiva #region di C# aiuta ad aumentare la leggibilità del codice e che la direttiva stessa non esiste direttamente in c++. Quello che forse non si sa è che le region sono utilizzabili con il C++ dal VS2005, attraverso la direttiva pragma. Ecco un piccolo snippet:

#pragma region Main

int main(array ^args)

{

Console::WriteLine(L"Hello World");

return 0;

}

#pragma endregion

Adesso non si hanno più scuse per non usare il c++/cli :)

Generics e alias

Gianluca Carucci — Fri, 23 Dec 2005 10:41:00 GMT

In c++, quando utilizziamo un template (prendiamo ad esempio il tipo std::vector), è pratica abbastanza diffusa definire un nuovo tipo del template specializzato.

Qualcosa di questo tipo per intenderci:

typedef std::vector IntVector;

Come sappiamo usare un template (o un tipo generico del framework) allunga incredibilmente il nome del tipo e risulta molto scomodo dover ripetere lo stesso nome per intero ad ogni cast, istanziazione etc etc. Esiste qualcosa di simile al tipedef anche in C#? La risposta è si, ma tenendo ben presente l'aggettivo SIMILE. In C# possiamo definire un alias utilizzando la key using. La "dichiarazione duale del tipo IntVector di c++, in c# sarebbe:

using IntList = System.Collection.Generic.List;

Leggere attentamente le avvertenze: lo statement using, come avviene con i namespace, definisce solo un alias, non esiste un vero e proprio equivalente del typedef del c++. Questo è supportato dal fatto che, una volta compilato il codice, nel nostro assembly non esisterà nessun metadata che fa riferimento al tipo IntList. Se proprio vogliamo definire un tipo specializzato del generic dobbiamo creare una classe che eredita dalla versione specializzata del tipo generico(magari può essere utile un codesnippet per questo).

Technorati tags: C++, using, template, generics

Per chi pensa che C# sia un mostro cattivo...

Gianluca Carucci — Mon, 25 Oct 2004 08:49:00 GMT

... e voglia portarsi via tutte le nostre vecchie e robuste applicazioni unmanaged, una frase (e un articolo) che chiarifica alcuni preconcetti:

"Some have speculated that C# is a replacement for C++, but it most certainly is not. C# is a language that is easier to learn than C++, and provides access to the functionality of the CLR. For those who already know C++, there's no need to learn anything to gain access to the functionality of the CLR, and C++ has features that are not in C#, so moving would actually involve giving up some power."

La frase è presa dall'articolo su MSDN "Moving to .NET and WinFX: a Roadmap for C/C++ Applications".

Buona lettura

Technorati tags: C++, C#

I Tempi che furono....

Gianluca Carucci — Wed, 20 Oct 2004 10:51:00 GMT

Ancora per poco, sfogliando l'msdn alla voce "Visual c++ Compiler Options: /Z7, /Zd, /Zi, /ZI (Debug Information Format)" possiamo trovare:

/ZI: "Produces a program database, as described above, in a format that supports the Edit and Continue feature. If you want to use Edit and Continue debugging, you must use this option. Because most optimizations are incompatible with Edit and Continue, using /ZI disables any #pragma optimize statements in your code.

/ZI causes /Gy to be used in your compilation.

/ZI is not compatible with /clr."

Sarà ancora così anche x il CLR 2.0? C# 2.0 ha ceduto, non ci resta che sperare ancora nel nuovo c++ managed:D

Initializer nei costruttori: C++ Vs C#

Gianluca Carucci — Fri, 03 Sep 2004 14:51:00 GMT

Spesso, programmando in c++, mi scontro con diversità nell'interpretazione (ed effettiva implementazione) della programmazione a oggetti rispetto al c#. Quando mi trovo in queste situazioni mi viene da pensare il motivo di questa differenza e perchè in fase di progettazione dei due linguaggi Straustrup e Hejlsberg sono arrivati a due conclusioni differenti. L'esempio più eclatante riguarda sicuramente la diatriba sull'ereditarietà multipla. In questo post invece mi volevo soffermare su un problema molto meno rilevante dell'esempio appena citato: l'initializer nei costruttori e in particolare richiamare nell'initializer un'altra versione del costruttore della classe.

In entrambi i linguaggi l'initializer è opzionale e in c# accetta solo costruttori, tramite la parola chiave this (che invoca un costruttore della stessa classe) o base (che invoca il costruttore della classe base). In c++ l'inizializer accetta solo o membri della classe oppure un costruttore della classe base, senza dare la possibilità di richiamare un altro costruttore della stessa classe. Vediamo un esempio:

Abbiamo una classe A e una classe B che eredita da A. Le dichiarazione delle classi è sostanzialmente analoga:

[C#]
public class A
{
private int _a;
//Constructor....
}
public class B: A
{
private int _b;
//Constructor...
}
[C++]
public class A
{
private:
int _a;
//Constructor....
};
public class B: public A
{
private:
int _b;
//Constructors....
};

La parte interessate riguarda l'implementazione dei costruttori. Vediamo i costruttori della classe A:
[C#]
public A() : this(0)
{}

public A(int a)
{
_a = a;
}
....
[C++]
public:
A(void) : _a(0)
{}

A(int a): _a(a)
{}

Le differenze tra i due linguaggi balzano subito agli occhi: In C# non possono essere inizializzati i membri nell'initializer (anche perchè in realtà non ci sarebbe differenza, se non sintattica, rispetto ad inizializzarli nel corpo del costruttore) mentre in c++ non può essere richiamata dal costruttore A(void) la versione del costruttore A(int a).
Vediamo ora i costruttori della classe B:
[C#]
public B() : this(0)
{}

public B(int b): this(0, b)
{}

public B(int a, int b): base(a)
{
_b = b;
}
....
[C++]
public:
B(void) : A(0), _b(0) //Richiamo del costruttore con un parametro della classe base e inizializzazione del membro _b
{}

B(int b): A(0), _b(b)
{}

B(int a, int b): A(a), _b(b)
{}

Dalla classe figlia B balza all'occhio ancora la comodità (e spesso necessità) del c++ di inizializzare i membri nell'initializer e l'impossibilità di richiamare una versione diversa del costruttore della classe. E' possibile invece richiamare un costruttore della classe figlia.
Come si dice in questi casi la domanda nasce spontanea: perchè inell'initializer, n c++, si può richiamare un costruttore della classe base e non un costruttore diverso della classe figlia? E' una scelta progettuale ed è dettata da una ragione ben precisa o più semplicemente in fase di progettazione del linguaggio non è stata proprio pensata una situazione di questo genere? Visto e considerato che C# è un linguaggio più nuovo, e permette questa situazione, mi viene da pensare che sia stata una "dimenticanza" del c++. La sensazione è che a questa domanda può rispondere solo Mr. Straustrup:)

Ai POSTeri l'ardua sentenza....

Non è Eric Gunnerson ma...

Gianluca Carucci — Wed, 19 Nov 2003 10:48:00 GMT

può essere interessante lo stesso:)

Per chi è appassionato del mondo dei videogiochi propongo un'interessante intervista fatta da Multiplayer.it... Bhè non vi svelo nulla:)

Il link è http://pc.multiplayer.it/articoli.php3?id=9484