|
I'm writing a transformfilter with 1 input and 2 output pins. I've derived my Transformfilter from CBaseFilter and the pins from CBaseInputPin and CBaseOutputPin. I'm pretty sure my Filter works because if I've only 1 Pin the sample process how it should, but if I add the second output pin the video stops with the first sample on one window a shows nothing on the second window.
When I debug the second time i call GetDeliveryBuffer i get the error code -2147220975.
Here is what i did in the method Receive:
hr = pOutputPin1->GetDeliveryBuffer(&pOutSample1, NULL, NULL, 0);
hr = Copy(pSample, pOutSample1);
hr = Transform1(pSample, pOutSample1);
hr = pOutputPin1->Deliver(pOutSample1);
pOutSample1->Release();
hr = pOutputPin2->GetDeliveryBuffer(&pOutSample2, NULL, NULL, 0);
hr = Copy(pSample, pOutSample2);
hr = Transform2(pSample, pOutSample2);
hr = pOutputPin2->Deliver(pOutSample2);
pOutSample2->Release();
What am i doing wrong?
|
|
|
|
|
You may get an answer, but generally DirectShow questions
don't get much love here.
I know there's a couple MVPs that really know this stuff....you can
find them here:
MSDN DirectX.Video Newsgroup[^]
Hope that helps!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi itchy,
I see you're getting a little help over on the other board.
I was just thinking, if you're delivering the same samples to both
output pins, why not just use a single output pin into an infinite tee filter?
Just a random thought,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Yeah I'm getting help, but up until now nothing is working.
I know I could use the inftee filter, but I don't want that because I'm making changes to both samples. If I use inftee filter I need to write 2 filters.
Besides its good practice, if it would work .
Thanks by the way for redirecting me.
|
|
|
|
|
|
Please post on the Visual C++/MFC board[^].
This board is for Managed C++/CLI questions only.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I have a Managed C++ Windows Forms program that I'm compiling in Visual Studio 2003. When I try to run it, it tells me "Program too big to fit in memory" in a command prompt.
Does anyone know why it would even pop up with a command prompt window when this is a Windows application? Secondly, why would I get this error? Sources from google tell me that usually, this has to do with a corrupt installer issue, but this is not an installer at all.
Thanks.
|
|
|
|
|
I think I might've found the issue. I believe it lies with trying to reference an unmanaged lib (not compiled with managed extensions in C++), from a project that is compiled into a managed executable (managed extensions enabled). From what I've read, it seems to me (so far) that the only way to do this is to use a .dll and PInvoke, but is there any way to simply use a .lib?
|
|
|
|
|
The lib should work fine. C++/CLI lets you call code in static and
dynamic libraries without p/invoke.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi Mark,
Thanks for the info, however, here's the problem. The first time I do a build, it always fails with a LNK1000 error where essentially, VC7's link.exe throws some kind of exception. If I try to build it again, it succeeds. Always. The only problem is, that the generated executable is invalid. At first, I couldn't figure out what was wrong. Then, because I suspected some kind of dependency issue, I ran depends.exe on the generated executable, and it told me that the PE header was invalid (or something to that effect). Then, that was where I suspected the managed/unmanaged stuff.
I should also note that I have a solution of 3 projects, 1 of which is the executable (managed), 1 of which is a static library (managed), 1 of which is a static library (unmanaged). If I remove the unmanaged static library from its reference list or dependency chain, building the executable complains about linker errors (as expected, since I have not defined the symbols). As soon as I add the unmanaged static library, I get the LNK1000.
|
|
|
|
|
Cyrilix wrote: 1 of which is a static library (managed)
I'm not sure how well that's going to work, nor can I find any
solid confirmation one way or the other.
Binding of managed types in a library is done at the assembly level.
I'm not sure how well the linker's going to handle that.
A managed class library (DLL) is the appropriate way to make a managed
library (even if it has native code in it as well).
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Well, the way it works is that I have a managed static lib that contains my __gc classes. Then, I have an unmanaged static lib depending on and using the managed static lib that contains regular (non __gc) classes, which is sort of my interface to the native world. I've been able to use this interface with other classes from native code without problem. Then, I have a Winforms app which depends on that native interface. Now that I think of this, it doesn't really make sense as to why I'm doing it this way. I'm sort of going Managed->Unmanaged->Managed... might as well see if I can cut out the middle layer.
|
|
|
|
|
Cyrilix wrote: I'm compiling in Visual Studio 2003
I definitely recommend moving to at least VS 2005 (VC 8) any way you can,
as soon as you can, before investing a lot of time in code that is incompatible
with newer/future C++ compilers.
With VC8+, you get the actual C++/CLI language instead of the Managed Extensions
you are using with VC7, which aren't supported anymore (there's a compiler switch
to allow it...for now).
The Managed Extensions for C++ syntax is deprecated.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I am pushing for this as well, but I'm not sure if I'll be able to convince them to allocate hours to upgrade our entire system before I finish this small project. Also, I think the Managed C++ in VC8+ definitely also looks much nicer in terms of syntax.
|
|
|
|
|
Hi,
I am porting my vc2003 app to vc2008 and have come across somthing like this...
LPCTSTR lpsz = _T("myString");
SomeObject *obj = Afunc( lpsz );
under vc2003 this compiles and works file however in vc2008 it seems that i need to do...
LPCTSTR lpsz = _T("myString");
SomeObject ^obj = Afunc( gcnew String(lpsz) );
the documentation on string literals in C++/CLI migration primer suggest that the following could be done.
SomeObject ^obj = AFunc( safe_cast<string^>(lpsz) );
this is wrong as it not compile.
I not sure the gcnew string( lpsz ) method is ideal. is there a better way or what is the propper way of doing this.
thanks
Robin
|
|
|
|
|
Robin Imrie wrote: I not sure the gcnew string( lpsz ) method is ideal. is there a better way or what is the propper way of doing this.
in general gcnew is how you create managed objects in C++/CLI so that is always a correct way to do it. Of course strings can be different like in Native C++ based on what you need them for. In your code you are creating a native string and then converting it to a managed string.
If you only need a managed string then you could do this.
System::String^ lpsz = "myString";
There is a series of introductory C++/CLI articles here on CodeProject. I suggest you take advantage of them.
led mike
|
|
|
|
|
Thanks mike for that i had suspected as much.
Will give the C++/CLI articles a good look.
|
|
|
|
|
Hi all,
We installed gtk from the following site
http://crossfire.real-time.com/clients/win32_gtk.html
please help us how to compile and run our own c++ files
Thank You
Sesha Sridhar
|
|
|
|
|
Hi to all,
I have an 'Windows Form Control Library' "VideoWindow.dll" in VC#.Net 2008, having code as following,
<block><br />
using DirectShowLib;
<br />
<br />
public partial class VideoWindow : UserControl<br />
{<br />
public VideoWindow()<br />
{<br />
InitializeComponent();<br />
}<br />
<br />
Label m_picVideoWindow = new Label();<br />
<br />
public int SetPreview(IVideoWindow vwRenderer)<br />
{<br />
int hr = 0;<br />
if (m_picVideoWindow.Bounds.IsEmpty)<br />
return hr;<br />
try<br />
{<br />
hr = vwRenderer.put_WindowStyle(WindowStyle.Child | WindowStyle.ClipChildren | WindowStyle.ClipSiblings);<br />
DsError.ThrowExceptionForHR(hr);<br />
hr = vwRenderer.put_Owner(m_picVideoWindow.Handle);<br />
DsError.ThrowExceptionForHR(hr);<br />
hr = vwRenderer.SetWindowPosition(0, 0, m_picVideoWindow.Width, m_picVideoWindow.Height);<br />
DsError.ThrowExceptionForHR(hr);<br />
hr = vwRenderer.put_Visible(OABool.True);<br />
DsError.ThrowExceptionForHR(hr);<br />
}<br />
catch (Exception ex)<br />
{<br />
}<br />
return hr;<br />
}<br />
}<br />
</block>
When I am calling SetPreview() from my VC++.Net 2008 MFC Application as follows,
<block><br />
IVideoWindow *pWidnow;
CWinFormsControl<VideoWindow::VideoWindow> *a1 = new CWinFormsControl<VideoWindow::VideoWindow>();<br />
<br />
(*a1)->SetPreview(pWidnow);<br />
</block>
It gives compile error as,
error C2664: 'VideoWindow::VideoWindow::SetPreview' : cannot convert parameter 1 from 'IVideoWindow *' to 'DirectShowLib::IVideoWindow ^'
Please help me to solve this error.
Regards,
Aniket A. Salunkhe
|
|
|
|
|
Aniket Salunkhe wrote: Please help me to solve this error.
Well a Native C++ pointer
Aniket Salunkhe wrote: IVideoWindow *pWidnow;
Is not going to be convertible to a managed object.
Aniket Salunkhe wrote: DirectShowLib::IVideoWindow ^
If you don't know that, then you need to do some studying of C++/CLI basics and fundamentals. There is a series of CLI beginner articles here on Code Project.
led mike
|
|
|
|
|
Aniket Salunkhe wrote: When I am calling SetPreview() from my VC++.Net 2008 MFC Application as follows,
IVideoWindow *pWidnow;//C++ DirectShow Library
CWinFormsControl<videowindow::videowindow xmlns:videowindow="#unknown"> *a1 = new CWinFormsControl<videowindow::videowindow>();
Handles to managed objects use ^, not * in C++.
Also you use gcnew, not new, to allocate them on the managed heap.
Aniket Salunkhe wrote: (*a1)->SetPreview(pWidnow);
Huh?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark, FYI, Aniket Salunkhe is trying to call managed code from native C++ according to this quote: "When I (Aniket Salunkhe) am calling SetPreview() from my VC++.Net 2008 MFC Application ...".
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
That was pretty obvious from the error message as well
I only commented about the syntax/language use.
I suppose I could have mentioned that (s)he'll have to
compile with /CLR.
Cheers,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: he'll have to
compile with /CLR.
I am already using this flag (/CLR).
|
|
|
|
|
I knew that from the error message.
You're using the wrong syntax for managed objects.
The error message is fairly clear.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|