[gst-devel] 0.9 and prerolling

[MDK]

On 9/13/05, Thomas Vander Stichele <thomas at apestaart.org> wrote:

> > By "prerolling" I mean creating the actual pads on avidemux. I'm aware
> > of the fakesink technique Ronald recently described in regard to
> > decodebin. But It doesn't really work here, since avidemux doesn't
> > emit "new pad" signals (the "temporary" fakesink would always timeout)
>
> as mentioned on IRC - did you try connecting to "pad-added" on
> avidemux ? Seems from the logs it's definately creating the pads.

Yes, that works (somehow, more on that later). I still think that the
idea of injecting fakesinks just to trigger sometimes-pads is pretty
inconvenient, but I understand that this is a side-effect of the
design that performs better when it comes to the actual processing.

> ...
> Second, there are more advanced use cases being considered.  One of them
> as you know is the video editor.  Edward is working on such a thing,
> just like you IIRC.  There's a bunch more targets people are thinking
> about explicitly or implicitly in the choices they make.
>
> What other advanced use cases do you want us to think of ?

I was thinking exactly about the case of a video editor. My
observation comes from the fact, that I was able to implement a pretty
much working timeline in one month with 0.8, and now I'm running
around in circles to get the basic things working in 0.9. And this is
not because of bugs. It's solely because I can't comprehend what
should be the right way to do things in 0.9. I already re-implemented
my design X times, each time discovering I'm doing something against
the GST 0.9 logic. This is not a rant or something -- I'm frustrated
at myself only.

One thing you particularly need in a video editor, is the ability to
access a single source (media file) many times. For example - in Diva
I'm using a separate bin/pipeline for generating frame thumbnails and
a separate one for the actual playback. Also, you need separate bins
(clones) for each instance of the media that the user puts on the
timeline.

You can't really re-create the bin each time using decodebin. That's
against the performance, since decodebin assembling implies decoding
first frame. Also, imagine one would like to load a file and start
playing from the 50'th frame. This is not possible without the
first-frame-always-decoded overhead (with decodebin).

I seriously think that the process of "loading" a file/inspecting
it/preparing for playback should be separated from the actual playback
(in design terms). You can't really make everything dynamic.

I'm trying now to achieve that separation with some custom statical
objects. But this is also painful since:

1. Prerolling [filesrc ! avidemux]
2. Attaching jpegdec

... will work only if you link the jpegdec in the new-pad signal.
Prerolling [filesrc ! avidemux] to "spawn" the pads and attaching
jpegdec later on dies with errors in the ring buffer (?) (when you try
to use that bin later on). I even know why is it so, and, once again,
I don't like the fact that we assume that everything is streamed at
the very moment it's constructed.

> > Another issue is the new threading system - which is great for simple
> > & fixed pipelines, but very limiting if you want to write some more
> > complicated stuff.
>
> I would love to answer but your statement is very vague.  Could you be
> more specific ?

I'll elaborate more on that soon I suppose. But for example - in Diva
I'm having a CacheManager object that operates in a separate thread.
It accepts "jobs" to decode frame thumbnails. In 0.8 the CacheManager
thread was manually iterating over bins (gst_bin_iterate) to generate
output. So all thumbnail sources were actually running in one thread.
No resources lost. That's not possible to recreate in 0.9.

Once again, I'm not complaining - just trying to share my experiences
regarding the particular problem of dynamical sources creating. On the
other end I'm implementing an advanced OpenGL sink, and things go as
smooth as they can.

--
Michał Dominik K.
michaldominik at gmail.com
www.mdk.org.pl