[gst-devel] Can a controller use a different clock?

[Roman Ekjanov]

On 6/5/07, Stefan Kost <ensonic at hora-obscura.de> wrote:
> Hi,
> Steve Fink wrote:
> > On 6/5/07, Stefan Kost <ensonic at hora-obscura.de> wrote:
> >> hi,
> >>
> >> Steve Fink wrote:
> >> <snip>
> >>> I want dynamic volume control with a stream that I am seeking around
> >>> within. Specifically, I want two very different types: (1) I want to
> >>> overlay a volume "track" on top of a stream where the volume at any
> >>> point is tied to the offset within that stream, and (2) I want a
> >>> volume adjustment that happens relative to playback time. #1 is used
> >>> when using a single source sound clip and making several variations,
> >>> where each variation has its own settings for what part of the clip
> >>> should be loud and what part should be soft. These variants will be
> >>> played back with occasional nonlinearities where I seek to different
> >>> points within the clip, and the same part of the clip for a given
> >>> variant should always have the same volume. #2 is used for fading out
> >>> the playback, probably because you're switching to something else. (It
> >>> may not be a global fade across all clips, though; there may be other
> >>> streams getting mixed in on their own timelines.)
> >> You schedule parameter changes as soon as you know when they should happen. If
> >> you want to fade out the volume as a result of a button click the I would query
> >> the position of the stream in the button-pressed callback and schedule two
> >> parameter changes [position,1.0],[position+(3*GST_SECOND),0.0]. Maybe adding a
> >> little to the first control-change position. Also set the interpolation mode to
> >> linear.
> >
> > This would not work for the usage I was describing, although it may be
> > that the usage I was describing is just not the way things are done in
> > gstreamer.
> >
> > I have an incoming stream, which I am not really using as a stream. I
> > play the first 1200ms, then seek to 03:00, then play another 1000ms,
> > then seek back to 00:05, play another bit, etc. I'm essentially using
> > a single stream as a randomly accessed series of clips, and seeking
> > within stream time to do the accesses. I'm making a distinction
> > between stream time and playback time because I'm seeking the stream
> > time all over.
> >
> > Your solution only works within stream time. If I happened to do a
> > seek at 1.5*GST_SECOND, then my fadeout would be "cancelled".
> >
> You want the fade to continue, despite you are seeking? Then you would need a
> element that re-stamps buffers and maybe put the audio decoding element into a
> bin and seek on that.
>
> >
> > Is the problem my usage of seeking? Should I have a nonlinear-audio
> > plugin that accepts my "seek" events (using a custom event rather than
> > the seek event) and produces a consistent, monotonically increasing
> > stream time like normal gstreamer streams? Can I partition the "time
> > domain" of portions of my pipeline?
> >
> I still have not a clear picture what you app should do. The concept of the
> controller is to bind parameter changes to timestamps.  Maybe its easier for you
> to have a idle-handler that does that changes based on playing time.
>
> Stefan
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
I think I understand. Is you sequence always the same? Does seek
produce a new segment? If so, you may want to look at identity
element, it has property single-segment.
Just a guess, most certainly useless.
---
   Roma