[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
>
I think I understand.I don't know if a new segment is generated for
every seek, but if it so, you may want to look at identity element, it
has property single-segment.
Just a guess, most certainly useless.
---
  Roma