Hi again Pat,
So, I've spent some time debugging this.. first, it really isn't easy to get
the environment setup! I'm wondering why you had to use that custom makefile
? Anyways, that's not important..
so, first, apart from not checking if CoInitialize returns
RPC_E_CHANGED_MODE (not S_FALSE as I previously thought), I don't believe
this issue was caused by a bug in tkvideo... after a lot of investigating, I
think there's actually a bug in the dshowaudiosrc element of gstreamer,
although I'm not entirely sure...
Anyways, the problem with the 'devices' command is that the command returns
TCL_ERROR but doesn't set the Tcl_Result, so we get the result that was
previously set by the Tcl_GetIndexFromObjStruct in tkvideo.c (which only
checks for cget, configure, xview and yview).
I also noticed that commands like '$win start' also return this same result
even if they succeed, because even if TCL_OK is returned, the Tcl_Result has
not been modified... I suggest reseting the Tcl_Result before calling the
subcommand's handler.
The reason why the GetDeviceList function returns TCL_ERROR is because the
call to CoCreateInstance returns 0x800401F0 which means "CoInitialize has
not been called."
So I'm guessing that maybe it's because the gstreamer element call
CoInitializeEx once when created, then they call CoUninitialize in their
dispose method (which could apparently be called more than once in some
cases.. so they should use finalize instead), and it *may* cause the COM
library to become uninitialized... I'll try to find out if that's true or
not... I also thought that maybe tkvideo initializes COM usnig CoInitialize
which initializes it as single threaded, but gstreamer initializes it as
multithreaded, so maybe changing the concurrency model made tkvideo's COM
uninitialized... A solution could be to initialize it when creating the
widget and uninitialize it once the widget is destroyed... (MSDN says that
the number of initialize/uninitialize is counted, so initializing 10 times
will need 10 uninitialize before the cOM library gets uninitialized for
real) . Although the code from dshowaudiosrc and dshowvideosrc is basically
the same, I found out that it only happens when audio is being tested with
gstreamer, so the problem is either in dshowaudiosrc or in
directsoundsink.... Anyways, I changed tkvideo's CoInitialize to
CoInitializeEx using multithreaded model, but the same problem happens, I
really don't know what could cause it to do that... I guess i'll have to
change the gstreamer elements not to class CoUninitialize and hope it fixes
it (note that it doesn't seem to always happen, so it's probably some kind
of race condition, but I've noticed it in maybe 90 or 95% of my tests).
So..that was the issue with gstreamer incompatibility and the 'devices'
command missing issue...
Anyways, I tried to check the 'black screen' issue I was getting, and I
realized it still happens for me even if gstreamer isn't loaded at all... so
maybe by some sort of coincidence I am able to reproduce the bug with the
"ACE mega codec pack" but without having that codec pack installed
myself...
Anyways, the problem seems to be that :
1 - in VideoStart, calling the Run method on IMediaControl returns an
"incorrect function" error, actually HRESULT is '1', which is S_FALSE, which
means for that method : "The graph is preparing to run, but some filters
have not completed the transition to a running state."
but the 'start' command still returns TCL_OK since S_FALSE is > 0 and so
isn't FAILED(hr)...
I checked a little later and it seems that if I try to run start again, this
time it says it's successful, so I guess the state change is just a little
bit delayed... However, the image stays always black and when we call [$win
picture] it fails when
calling GetCurrentBuffer on the pSampleGrabber.. the HRESULT is 0x80040227
which seems to be VFW_E_WRONG_STATE... which you define as "image capture
failed: no samples are being buffered"...
That's about it.. I don't really know if I can dig any deeper and find
something to fix this, I barely understand any of this, so I really don't
know what's wrong.. if you can help me, I'd be very grateful, thank you!
p.s.: sorry for the long email!
KaKaRoTo
On Tue, Aug 18, 2009 at 4:23 PM, Youness Alaoui <
kakar...@kakaroto.homelinux.net> wrote:
> Hi Pat,
> We're having some TkVideo issues with aMSN...
> First, the issue I told you about over IRC a while back :
> http://www.amsn-project.net/forums/viewtopic.php?t=6370
> That issue is about TkVideo showing only a black screen if the "ACE mega
> codec pack" is installed on the system..
> The second issue happens quite often too, it seems that if we create a
> tkvideo window, then destroy it, sometimes (once it starts, it will always
> reproduce itself) when we create a tkvideo window, the tkvideo will only
> have 'configure' and 'cget' commands available, so it crashes on "$win
> devices" saying that 'devices' is not a valid subcommand...
> The third and most problematic issue we currently have (a release-blocker
> actually) is that if gstreamer is loaded into aMSN, then TkVideo will either
> :
> - fail to load if it wasn't loaded before
> - show a black screen or a frozen frame if the package was loaded
> before...
> I don't have much more detail about this right now... I checked your SVN
> and it doesn't look like you've fixed anything related to this lately (last
> change was 2 years ago I think)..
> Once I get home tonight, I'll try to debug and see what the problem is...
> humm... I just took a quick look at the code to figure out why Tkvideo_Init
> would return TCL_ERROR and it looks like in winvideo.cpp, the only reason
> for TCL_ERROR to be returned is this :
> VideopInit(Tcl_Interp *interp)
> {
> HRESULT hr = CoInitialize(0);
> return SUCCEEDED(hr) ? TCL_OK : TCL_ERROR;
> }
>
> So I guess CoInitialize(0) does not succeed... from the MSDN reference :
> http://msdn.microsoft.com/en-us/library/ms678543(VS.85).aspx
> It says that it would return S_FALSE if "The COM library is already
> initialized on this thread." So I think your code should handle the case
> where the COM library was already initialized...
> You should actually only check for : E_INVALIDARG, E_OUTOFMEMORY, and
> E_UNEXPECTED.
> For why it only shows a black screen, I don't know yet, I'll investigate
> this a bit more tonight...
> I would really appreciate if you could give me a hand on this, as I don't
> know any of your code and have zero knowledge on the win32 API...
> If you want to reproduce the issue, grab amsn's SVN (
> http://amsn-project.net/wiki/SVN) all the binaries for windows are
> precompiled and in the SVN repository, so no compilation needed.. launch
> aMSN, and press Ctrl-N to go to the audio and video assistant, in there go
> all the way to the end so gstreamer gets loaded and the video source
> elements are initialized, then launch it again to see how Tkvideo behaves in
> the second step of the assistant (or play with it manually using the tcl
> shell that you can get by pressing Ctrl-Shift-C from the main window).
> If you want to talk to me, I should be available on IRC as KaKaRoTo or
> KaKaRoTo-KS.
> Thanks,
> KaKaRoTo
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
