[gst-devel] 'original' recording while playing

Julien Isorce julien.isorce at gmail.com
Mon Jun 28 10:17:40 CEST 2010


I am facing to a problem that I am sure it's pretty common for some of you.
Giving an uri, I am using uridecodebin to automatically select/connect the
source and the decoders.
Then I am usually connecting an identity element to grab frames for image
processing purposes.
I am also recording the stream but I re-encode it because I need to record
what I analysed. (It's not exactly what I analysed
but I can see jerks and image contents, black frames etc..).

Now I would like to save the original stream. I mean before decoding it.
Here are the steps:

- use uridecodebin
- in autoplug-continue callback, retrieve the decodebin2 element, get its
sink pad and call gst_pad_set_blocked_async(TRUE)
on the peer pad.
- in the associated GstPadBlockCallback, unlink those two pads in order to
just insert a tee element and relink them.
- then create and connect a queue2->filesink to this tee element
- unblock the pad
- set the newer elements (tee, queue2, filesink) to playing state

So before to be demuxed, the stream is pushed into a file.

*The first problem is that I do not know how to properly and automatically
select the file extension (ogg, flv, mp4...)
Note that for now I am using the uri extension maybe there is a proper way
to do that.
*The second problem is at pipeline shutdown because now just sending an eos
event from the pipeline is not working (eos message never comes on the bus)
So it's due to the add of the branch tee->queue2->filesink.
I have to block the queue2 's source pad, and send an eos event from this
filesink element, then unlink queue2, set queue2 and filesink to NULL state,
and finally send an eos event from the pipeline. In order to be able to
catch an eos message on the bus.

Well I am not sure this is the best way to record a stream without decoding
it. I know that the stream should be remuxed in order to have the correct
origin for the timetsamps, and to have the index correctly written for some

*So my 3 questions are: *

-- Is this goal really too specific and not common to be done in this
manually way each time someone wants to achieve it ?

--In the case there is not a more immediate way, could we imagine a filename
property on uridecodebin for this goal ?

--If something like the following functions do not exsit yet, would it be
usefull to add api to dynamically insert new elements between existing
playing elements:
(I can read a lot of mail where the solution is block a pad, unlink, set
state, insert, send event, unblock, etc...) ?

gst_element_insert_downstream_async(element, new_element, callback) would
try to insert 'new_element' the closest possible to 'element' in the
dwonstream way.
gst_element_insert_upstream_async(element, new_element, callback).
gst_element_insert_between_async(downstream_element, up_stream_element,
new_element, callback)
(well maybe gst_bin_... would be more appropriate, but gst_element_link has
those kind of bin considerations too)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100628/b8e355d9/attachment.htm>

More information about the gstreamer-devel mailing list