[gst-devel] loop-to-loop scheduling problems

[Ronald Bultje]

Hi *,

something else, just for fun. I've had an issue lately where I put
multiple loop-based elements in one pipeline. This is for a new (yet
uncommitted) plugin, a video muxer. It's different from avimux
(loop-based too), but I'll come to that.

The issue is that, since I'm loopbased, I am free to pad_pull() whenever
I want, even before capsnego has started/finished. This is an issue,
since in many cases, capsnego is only finished *during* pipeline
iteration, not before. I need a way around that, I first need the
capsnego result, and only *then* should I pad_pull(). That's how the
plugin works, unfortunately. So what I need, is a way to delay my
loopfunc from being called until capsnego is finished, or to 'sleep' in
my loopfunc until capsnego is completed.

I first thought gst_pad_select() was meant for this (it waits until a
buffer is available, which automatically means that capsnego has also
been performed), but as our scheduling people will know, this is how opt
implements that:

static void
gst_opt_scheduler_pad_select (GstScheduler *sched, GList *padlist)
{
  //GstOptScheduler *osched = GST_OPT_SCHEDULER (sched);

  g_warning ("pad select, implement me");
}

Nice, uh? :).

Now, why don't I see this in avidemux? I'm using a hack there: I'm first
pulling data from all pads into my internal element queue (one buffer
per pad), and after that, I start processing. this means that when I
start processing, capsnego is finished on all pads. ;). This is,
unfortunately, not possible in my current element. I need something
else.

Anyone?

Ronald

PS: what I want to do is this:

gst-launch { mplex name=mux ! filesink location=file.mpg } filesrc
location=file.avi ! avidemux name=demux .video_00 ! { queue !
ffdec_mpeg4 ! ffcolorspace ! mpeg2enc ! queue ! mux.video_00 }
demux.audio_00 ! { queue ! mad ! ffenc_ac3 ! queue ! mux.audio_00 }

(mpeg2enc, mplex and avidemux are all loopbased.)

PS2: the old mplex didn't have this issue either because for each
mediatype, it used a different pad template (and thus, capsnego is not
needed). I don't consider that a fix either...

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