[gst-devel] caps doesn't remember?

[David Schleef]

On Wed, Dec 24, 2003 at 01:23:56PM +0100, Ronald Bultje wrote:
> Hi,
> 
> pipeline:
> gst-launch filesrc location=/media/clips/Trance\ Energy\ 2002\
> DvDSebRip.avi ! avidemux .video_00 ! { queue ! ffdec_mpeg4 !
> ffcolorspace ! ximagesink }
> 
> I added g_print in avidemux right before try_set_caps() and in ffdec
> right at the start of the link function:
> 
> AVI caps: video/x-divx, divxversion=(int)5, framerate=(double)25.000000,
> width=(int)640, height=(int)464
> Incoming: video/x-divx, divxversion=(int)5, framerate=(double)0.000000,
> width=(int)16, height=(int)16
> 
> How can that be? 16 and 0.0 are the lowest values in the pad template on
> avidemux's src pads, but they shouldn't be here. Is something going bad
> here? What's mainpulating caps in between try_set_caps() and the link
> function call?

It's likely that this is the negotiation that happens before the
try_set_caps().  In the cases that I've seen, it's harmless, although
surprising and a bit annoying while debugging.  The try_set_caps()
merely renegotiates the link, in a similar way to how try_set_caps()
works for ximagesink to renegotiate the size.

In the long run, it will be wise to have a "don't bother negotiating"
flag on a pad.  That "long run" may end up being next week.

If this doesn't describe what you're seeing, then it's a problem.

> Also ffmpegdec calls if (!GST_PAD_CAPS (pad)) { ... set caps ...} on its
> own src side. This is called (successfully!) during each iteration,
> which doesn't really help either. GST_PAD_CAPS() always returns null.

Oops, this is a bug.



dave...