After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 162634 - [PATCH] New plugin "clip" for partial media stream processing
[PATCH] New plugin "clip" for partial media stream processing
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.6
Other All
: High enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-12-31 18:33 UTC by Paul Jack
Modified: 2005-03-25 21:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8


Attachments
Source code for new clip plugin. (4.24 KB, application/x-gzip)
2004-12-31 18:35 UTC, Paul Jack
Details

Description Paul Jack 2004-12-31 18:33:26 UTC
Hope this is kosher, I'm not sure if a new plugin counts as a "PATCH" or not. 
The soon-to-be-attached .tar.gz file contains the .h and .c for the plugin and a
README, which I've pasted below.  Hope it's okay to attach binary files...

From the README:

So the purpose of this plugin/element is to allow processing of a partial media
stream.

The start and end points can be set using properties (start-offset and
end-offset).  Currently only time format is supported, so start-offset and
end-offset are expressed in nanoseconds.  If unspecified, the defaults will play
the entire stream.

When a buffer arrives, the clip element checks if that buffer's timestamp is
less than the start-offset.  If so, clip sends a seek event upstream (to
start-offset), and the buffer is disposed instead of pushed.  Otherwise, clip
checks if the buffer's timestamp is greater than or equal to the end-offset.  If
so, clip sends a seek event upstream (to the stream's total duration), and the
buffer is disposed instead of pushed.  If the buffer's timestamp is between
start-offset (inclusive) and end-offset (exclusive), then the buffer is pushed
downstream.

clip will not work if the upstream element does not support seeking.

Note that if start-offset is the same as end-offset, then exactly one frame will
be sent downstream by clip.

EXAMPLE USAGE:

gst-launch-0.8 filesrc location=x 
! spider 
! clip start-offset=y end-offset=y
! pngenc
! filesink location=z

The above is a command-line tool to take a snapshot of the frame at time offset
y in file x.  Without clip, there isn't a way to use gst-launch to take a
snapshot of anything other than the first frame; developers would have to write
tricky iterate loops to perform this common operation.

Another scenario is that of a video non-linear editor, in which start and end
points are selected by the end user and a string of clipped streams are played
back or exported.
Comment 1 Paul Jack 2004-12-31 18:35:23 UTC
Created attachment 35327 [details]
Source code for new clip plugin.

Attached archive contains: 

gstclip.h
gstclip.c
README
Comment 2 Maciej Katafiasz 2005-01-10 00:51:59 UTC
Yes, your usage of bugzilla is perfectly kosher, congratulations :). Bumping
prio to High, will take closer look in next few days, unless someone is faster.
Comment 3 Ronald Bultje 2005-03-25 18:10:07 UTC
Hi Paul,

the bugzilla usage is good, and our patch review time is amazingly bad. Anyway,
... The first idea is good, this is indeed a quick way to do partial clip
processing. It has some shortcomings: ideally, if you reach the end point, you
want to EOS the whole thing right away. For that to work correctly, it has to be
a managing bin, i.e. a bin around all of its preceeding elements.

Cupid and gnome-sound-recorder (and probably pitivi, too) already use that
concept in one way or another. Basically, for this to work correctly, the
element gets very specialistic and non-straightforward. I generally tend to
consider gst-plugins the wrong place for this. I'd prefer it to be added to
something like gnonlin, which is more suited towards this kind of media
processing (gnonlin is a wrapper around GStreamer for this kind of media editing
features).

That doesn't mean the patch is wrong, but this is simply the wrong place, imo.
I'm leaning towards a WONTFIX...
Comment 4 Ronald Bultje 2005-03-25 21:32:48 UTC
Bit more thinking made me confirm that this is indeed out-of-scope. Again,
nothing wrong with your patch, just not the right place.

Thanks still.