Problem connecting a IAT YUV with video out pin of Mpeg Video decoder.

Problem connecting a IAT YUV with video out pin of Mpeg Video decoder.

Post by Michael Ku » Wed, 13 Apr 2005 01:20:09


Hello,

I have a video out pin of a Mpeg Video decoder filter (Invervideo for
Technotrend), graphedit tells me that it supports the following media
formats:
Major Type: Video - Sub Type: YUY2 - Format: YUY2 720x576, 16 bits,
Aspect Ratio: 4x3, Interlace format: Frames rcSrc=(0,0,0,0)
rcDst=(0,0,720,576)
Major Type: Video - Sub Type: YUY2 - Format: YUY2 720x576, 16 bits,
Aspect Ratio: 4x3, Interlace format: Frames rcSrc=(0,0,0,0)
rcDst=(0,0,720,576)
Major Type: Video - Sub Type: YV12 - Format: YV12 720x576, 12 bits,
Aspect Ratio: 4x3, Interlace format: Frames rcSrc=(0,0,0,0)
rcDst=(0,0,720,576)
Major Type: Video - Sub Type: YV12 - Format: YV12 720x576, 12 bits,
Aspect Ratio: 4x3, Interlace format: Frames rcSrc=(0,0,0,0)
rcDst=(0,0,720,576)

I have a YUV IAT filter (0x4CB4FBB2, 0x1342, 0x48FE, 0x81, 0x29, 0x5A, 0x7C,
0x47, 0x06, 0xD6, 0x0C)

When I try to connect the described outpin of the Intervideo mpeg decoder
with the input pin of the YUV IAT (from within my sample application), I get
the error code: 0x80040217
(I have a german windows, so a rough translation for the error text: "Can
not find intermediate filter to create connection")

BTW Iam using:
IGraphBuilder::Connect() for connecting the 2 pins of my filters.


But when I try to connect these 2 filters with graphedit its working.


So how is graphedit trying to connect pins? Or could you tell me what Iam
missing.


Best Regards
Michael
 
 
 

Problem connecting a IAT YUV with video out pin of Mpeg Video decoder.

Post by Iain » Wed, 13 Apr 2005 02:51:01


Graphedit does not do anything particularly clever with connections.

YOu maight try grabbing the graph from your program just before the
connection and comparing it to your graphedit graph.

Also (though it sounds like it does not apply in this case), many MPEG
decoders will ONLY connect in certain environments in order to prevent
encrytped streams being captured by an unauthorised application.

Iain

--
Iain Downs (DirectShow MVP)
Software Product Consultant
www.idcl.co.uk

 
 
 

Problem connecting a IAT YUV with video out pin of Mpeg Video decoder.

Post by Michael Ku » Wed, 13 Apr 2005 03:15:51

He Iain,

Thanks for the reply.


"Iain" < XXXX@XXXXX.COM > schrieb im Newsbeitrag

Iam

The Graphs are identically. As I did not create the graph with graphedit, I
simply registered the graph
of my application within the ROT and opened it with graphedit. Then I saw
the graph and the ( *** <g>) not
connected IAT YUV and I simply stopped the graph with graphedit and tried to
connect the blocks and it worked.


I also think that my mpeg decoder does not have such limitations, as its
part of the BDA driver for a DVB-C card of
technotrend, which are providing a kind of SDK for the card as well.



Regards
Michael
 
 
 

Problem connecting a IAT YUV with video out pin of Mpeg Video decoder.

Post by Michael Ku » Wed, 13 Apr 2005 03:29:57

The difference between my program and graphedit (using the same graph) seems
to be time.
During building my graph Iam using a NullRenderer device as a placeholder,
for the mentioned YUV IAT Filter.

My Order of operations was:
-Remove the NullRenderer from the graph
-Add the YUV IAT to the graph ==> FAILED


which did not work but the following works:
-Remove the NullRenderer from the graph
-Sleep(1000)
-Add the YUV IAT to the graph => OK


So I wonder does the graph need some time after a filter has been removed
before its an a proper state again?
How can I check this?
My Sleep(1000) approach is not very sathisfying.



Regards
Michael
 
 
 

Problem connecting a IAT YUV with video out pin of Mpeg Video decoder.

Post by Iain » Wed, 13 Apr 2005 05:26:29


One (VERY IRRITATING) think I have seen happen is this.

During format negotiation it is sometimes desired to reconnect the input
pins in order to make the output pins connect.

When this need occurs, the input pin will issue a QueryAccept with a new
format and the upstream pin will respond with yes or no.

If the answer is yes then the filter asks the graph to reconnect with the
new format.

Now the graph does this on a new thread rather than complicate
synchronisation in an existing thread, but the request just assumes it will
work and returns S_OK.

If this connection actually fails there is no means of informing the
original caller that it failed.

I have seen situations where this occured and the connection actually
failed, but where a retry a little while later worked. I would guess that
there is some synchronisation issue here.

My work around is simply to attempt to reconnect the graph if it all fails.

I'm not sure if my recollection is correct on the details and you more or
less have to be debugging the filter to track this, but it sounds similar.

I *think* my problem was with one of the ASF filters, not MPEG, but it
*may* have been MPEG.


HTH


Iain
--
Iain Downs (DirectShow MVP)
Software Product Consultant
www.idcl.co.uk
 
 
 

Problem connecting a IAT YUV with video out pin of Mpeg Video decoder.

Post by Michael Ku » Wed, 13 Apr 2005 15:46:31


"Iain" < XXXX@XXXXX.COM > schrieb im Newsbeitrag


fails.

Thanks Ian, this exactly the solution I was thinking of: "Retry on error",
although this is not the most sathisfying one, its at least better
than waiting for a magic time period.


Regards
Michael
 
 
 

Problem connecting a IAT YUV with video out pin of Mpeg Video decoder.

Post by Iain » Wed, 13 Apr 2005 18:25:29


But you probably still have to wait a while before checking the
connectedness of the graph so that the secondary thread has a chance to
fail.

Iain
--
Iain Downs (DirectShow MVP)
Software Product Consultant
www.idcl.co.uk
 
 
 

Problem connecting a IAT YUV with video out pin of Mpeg Video decoder.

Post by Michael Ku » Fri, 15 Apr 2005 03:59:25


"Iain" < XXXX@XXXXX.COM > schrieb im Newsbeitrag




error",

You are right, of course.
But I noticed a very strange behaviour.

When I try a "Sleep(500") before connecting it is working. At least on my
machine, I dont have any other with the TV card installed yet.
But when I have something like:

do{
Sleep(100);
// Try to connect.
}while(connected);

It does not take aprox. 5 trials for a successfuly connection (as someone
could have guessed) it takes more than 20. :-) So it seems that my "trial
connect" bothers the graph so that
I have to wait even longer.

Anyway I think I will go one step back and review my overall graph /graph
building design, as I would not like to have something like Sleep(500) fix
within my code.


Best Regards
Michael