[gst-devel] New DXR3 components and scheduling problem

[Ronald Bultje]

Hey Martin,

On Mon, 2003-03-31 at 21:16, Martin Soto wrote:
> Well, actually my initial idea was two have just one pad, since the card
> cannot play PCM and AC3 at the same time anyway.  I implemented the
> whole stuff and it works (effectively using a pad that accepts both mime
> types) except that after you play sound of one type, you cannot change
> anymore to the other type.

(I'm assuming you use gst_pad_try_set_caps() for this?)

> Investigating the problem, I saw that the sink pad apparently locks
> itself into the mime type that you used, and won't accept the other type
> afterward.  That's a problem while playing DVDs, because there are DVDs
> that change back and forth between the two types of sound (I have one
> that uses AC3 for the menus, and PCM for the film, go figure...)
> 
> That's why I opted for the two pad solution, even despite of the fact
> that the two pads are not intended to be used simultaneously.  But
> probably I need to fix the pad linking and relinking stuff instead.

I think so. This is really supposed to work. Of course, like so many
things, it's untested. ;-). If I'm correct, doing gst_pad_try_set_caps()
from the (source/mpexdemug) element should just re-trigger capsnego on
the sink element (dxr3audiosink). If it doesn't, that's probably a bug.

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer