gstreamer-devel Digest, Vol 4, Issue 5
Mihai Stoica
mihai.stoica at gmail.com
Wed May 4 06:21:24 PDT 2011
On Tue, May 3, 2011 at 2:07 PM,
<gstreamer-devel-request at lists.freedesktop.org> wrote:
> Send gstreamer-devel mailing list submissions to
> gstreamer-devel at lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> or, via email, send a message with subject or body 'help' to
> gstreamer-devel-request at lists.freedesktop.org
>
> You can reach the person managing the list at
> gstreamer-devel-owner at lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gstreamer-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Reading of GST tags with explicit pipeline and not
> decodebin/playbin (Stefan Kost)
> 2. Should h264parse limit the max PPS id to 31 or 255?
> (Karen Schoener)
> 3. Re: [0.11] gstreamer: event: add sticky flags to events
> (Stefan Kost)
> 4. Re: [0.11] gstreamer: event: add sticky flags to events
> (Jos? Alburquerque)
> 5. Re: How to remove a source of a Adder while playing?
> (Lucas Alberto)
> 6. Re: cross-compiling and `orc.m4` (Maarten Bosmans)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 02 May 2011 22:11:19 +0300
> From: Stefan Kost <ensonic at hora-obscura.de>
> Subject: Re: Reading of GST tags with explicit pipeline and not
> decodebin/playbin
> To: Discussion of the development of and with GStreamer
> <gstreamer-devel at lists.freedesktop.org>
> Cc: Mihai Stoica <mihai.stoica at gmail.com>
> Message-ID: <4DBF01D7.2050109 at hora-obscura.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Am 02.05.2011 18:02, schrieb Mihai Stoica:
>> Hi,
>>
>> I have some issues trying to extract GST tags from a mov file.
>> Because of performance requirements I don't want to use a decoder.. so
>> the pipeline would be similar to:
>> gst-launch filesrc location=./movie.mov ! qtdemux ! fakesink --tags,
>> but written with GStreamer API with C.
>>
>> If I execute this pipeline in command line I can see all tags being
>> extracted, but when trying to execute the C code no GST_MESSAGE_TAG is
>> being received.
>> If I replace qtdemux with decodebin without doing other changes to the
>> code... tag messages are being captured without any issues.
>>
>> Could anyone give me a hint about what am I doing wrong ?
>
> I don't see anything obvious right now, but wonder why you are not using
> GstDiscoverer instead.
>
> Stefan
This sounds like a great idea but unfortunately this API was added in
0.10.31 and I must stick with 0.10.30.
Thank you Stefan.
>
>>
>> The code would be like this:
>>
>> static GstElement *
>> create_decodebin_pipeline (MetadataExtractor *extractor, const gchar *uri)
>> {
>> GstElement *pipeline = NULL;
>>
>> GstElement *filesrc = NULL;
>> GstElement *bin = NULL;
>>
>> pipeline = gst_element_factory_make ("pipeline", NULL);
>> if (!pipeline) {
>> g_warning ("Failed to create GStreamer pipeline");
>> return NULL;
>> }
>>
>> filesrc = gst_element_factory_make ("giosrc", NULL);
>> if (!filesrc) {
>> g_warning ("Failed to create GStreamer giosrc");
>> gst_object_unref (GST_OBJECT (pipeline));
>> return NULL;
>> }
>>
>> bin = gst_element_factory_make ("qtdemux", "qtdemux");
>> if (!bin) {
>> g_warning ("Failed to create GStreamer qtdemux");
>> gst_object_unref (GST_OBJECT (pipeline));
>> gst_object_unref (GST_OBJECT (filesrc));
>> return NULL;
>> }
>>
>> g_object_set (G_OBJECT (bin), "name", "demux", NULL);
>>
>> g_signal_connect (G_OBJECT (bin),
>> "pad-added",
>> G_CALLBACK (dbin_dpad_cb),
>> extractor);
>>
>> gst_bin_add (GST_BIN (pipeline), filesrc);
>> gst_bin_add (GST_BIN (pipeline), bin);
>>
>> if (!gst_element_link_many (filesrc, bin, NULL)) {
>> g_warning ("Could not link GStreamer elements");
>> gst_object_unref (GST_OBJECT (pipeline));
>> return NULL;
>> }
>>
>> g_object_set (G_OBJECT (filesrc), "location", uri, NULL);
>>
>> extractor->bin = bin;
>>
>> return pipeline;
>> }
>>
>>
>> static void
>> dbin_dpad_cb (GstElement* e, GstPad* pad, gboolean cont, gpointer data_)
>> {
>> MetadataExtractor *extractor = (MetadataExtractor *)data_;
>> GstElement *fsink;
>> GstPad *fsinkpad;
>> GValue val = {0, };
>>
>> fsink = gst_element_factory_make ("fakesink", NULL);
>>
>> /* We increase the preroll buffer so we get duration (one frame not enough)*/
>> g_value_init (&val, G_TYPE_INT);
>> g_value_set_int (&val, 51);
>> g_object_set_property (G_OBJECT (fsink), "preroll-queue-len", &val);
>> g_value_unset (&val);
>>
>> extractor->fsinks = g_list_append (extractor->fsinks, fsink);
>> gst_element_set_state (fsink, GST_STATE_PAUSED);
>>
>> gst_bin_add (GST_BIN (extractor->pipeline), fsink);
>> fsinkpad = gst_element_get_static_pad (fsink, "sink");
>> gst_pad_link (pad, fsinkpad);
>> gst_object_unref (fsinkpad);
>> }
>>
>>
>> static gboolean
>> poll_for_ready (MetadataExtractor *extractor,
>> GstState state, /* GST_STATE_PAUSED */
>> gboolean ready_with_state, /* TRUE */
>> gboolean ready_with_eos) /* FALSE */
>> {
>>
>> gint64 timeout = 5 * GST_SECOND;
>> GstBus *bus = extractor->bus;
>> GstTagList *new_tags;
>>
>> gst_element_set_state (extractor->pipeline, state);
>>
>> while (TRUE) {
>> GstMessage *message;
>> GstElement *src;
>>
>> message = gst_bus_timed_pop (bus, timeout);
>>
>> if (!message) {
>> g_warning ("Pipeline timed out");
>> return FALSE;
>> }
>>
>> src = (GstElement*)GST_MESSAGE_SRC (message);
>>
>> switch (GST_MESSAGE_TYPE (message)) {
>> case GST_MESSAGE_TAG: {
>>
>> gst_message_parse_tag (message, &new_tags);
>> add_tags (new_tags, extractor);
>> gst_tag_list_free (new_tags);
>> break;
>> }
>> default:
>> /* Nothing to do here */
>> break;
>> }
>>
>> gst_message_unref (message);
>> }
>>
>> g_assert_not_reached ();
>>
>> return FALSE;
>> }
>>
>> Thanks,
>> Mihai.
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 2 May 2011 15:12:37 -0400
> From: Karen Schoener <kschoener at gmail.com>
> Subject: Should h264parse limit the max PPS id to 31 or 255?
> To: gstreamer-devel at lists.freedesktop.org
> Message-ID: <BANLkTikZwm_Afuv5wG25hR5c-JGt83KWWg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I notice that the h264parse element currently limits the max PPS id to 31.
>
> According to section 7.4.2.2 in the H264 spec, the PPS id may range from
> 0-255. However the SPS id can range from 0-31.
>
> Here's the info from 7.4.2.2 in the H264 spec:
>
> pic_parameter_set_id identifies the picture parameter set that is referred
> to in the slice header. The value of pic_parameter_set_id shall be in the
> range of 0 to 255, inclusive.
>
> seq_parameter_set_id refers to the active sequence parameter set. The value
> of seq_parameter_set_id shall be in the range of 0 to 31, inclusive.
>
>
> I was just wondering if this PPS ID limit to 31 was intentional.
>
> Does anyone see an issue with changing the following #define in h264parse.h
> from 32 to 256?
>
> #define MAX_PPS_COUNT 32
>
>
> Thanks, Karen
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110502/6b4453d5/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 02 May 2011 23:15:25 +0300
> From: Stefan Kost <ensonic at hora-obscura.de>
> Subject: Re: [0.11] gstreamer: event: add sticky flags to events
> To: gstreamer-devel at lists.freedesktop.org
> Cc: Wim Taymans <wtay at kemper.freedesktop.org>,
> gstreamer-commits at lists.freedesktop.org
> Message-ID: <4DBF10DD.2090209 at hora-obscura.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Am 02.05.2011 19:35, schrieb Wim Taymans:
>> Module: gstreamer
>> Branch: 0.11
>> Commit: 2243adffa128c6f508b0926ee00bfb1b18fead5e
>> URL: http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=2243adffa128c6f508b0926ee00bfb1b18fead5e
>>
>> Author: Wim Taymans <wim.taymans at collabora.co.uk>
>> Date: Mon May 2 18:34:18 2011 +0200
>>
>> event: add sticky flags to events
>>
>> Add the sticky flag to events and a sticky index.
>> Keep sticky events in an array on each pad.
>> Remove GST_EVENT_SRC(), it is causing refcycles with sticky events, was not used
>> and is not very interesting anyway.
>
> What about using something like g_object_add_weak_pointer() - too heavy for
> miniobjects?
>
> Stefan
>
>>
>> ---
>>
>> gst/gstevent.c | 9 +------
>> gst/gstevent.h | 67 +++++++++++++++++++++++++++++--------------------------
>> gst/gstinfo.c | 6 +---
>> gst/gstpad.c | 33 +++++++++++++++++++--------
>> gst/gstpad.h | 1 +
>> 5 files changed, 62 insertions(+), 54 deletions(-)
>>
>> Diff: http://cgit.freedesktop.org/gstreamer/gstreamer/diff/?id=2243adffa128c6f508b0926ee00bfb1b18fead5e
>> _______________________________________________
>> gstreamer-commits mailing list
>> gstreamer-commits at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-commits
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 02 May 2011 18:24:40 -0400
> From: Jos? Alburquerque <jaalburquerque at cox.net>
> Subject: Re: [0.11] gstreamer: event: add sticky flags to events
> To: Discussion of the development of and with GStreamer
> <gstreamer-devel at lists.freedesktop.org>
> Cc: Wim Taymans <wtay at kemper.freedesktop.org>, jaalburquerque at cox.net,
> gstreamer-commits at lists.freedesktop.org
> Message-ID: <1304375080.8690.14.camel at jose-desktop>
> Content-Type: text/plain; charset="UTF-8"
>
> On Mon, 2011-05-02 at 23:15 +0300, Stefan Kost wrote:
>> Am 02.05.2011 19:35, schrieb Wim Taymans:
>> > Module: gstreamer
>> > Branch: 0.11
>> > Commit: 2243adffa128c6f508b0926ee00bfb1b18fead5e
>> > URL: http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=2243adffa128c6f508b0926ee00bfb1b18fead5e
>> >
>> > Author: Wim Taymans <wim.taymans at collabora.co.uk>
>> > Date: Mon May 2 18:34:18 2011 +0200
>> >
>> > event: add sticky flags to events
>> >
>> > Add the sticky flag to events and a sticky index.
>> > Keep sticky events in an array on each pad.
>> > Remove GST_EVENT_SRC(), it is causing refcycles with sticky events, was not used
>> > and is not very interesting anyway.
>>
>> What about using something like g_object_add_weak_pointer() - too heavy for
>> miniobjects?
>
> There's a bug opened about adding a feature to ensure that data
> associated with mini objects for bindings can be properly freed when the
> mini objects are destroyed. This would be another option to fix that
> bug:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=609473
>
>>
>> Stefan
>>
>> >
>> > ---
>> >
>> > gst/gstevent.c | 9 +------
>> > gst/gstevent.h | 67 +++++++++++++++++++++++++++++--------------------------
>> > gst/gstinfo.c | 6 +---
>> > gst/gstpad.c | 33 +++++++++++++++++++--------
>> > gst/gstpad.h | 1 +
>> > 5 files changed, 62 insertions(+), 54 deletions(-)
>> >
>> > Diff: http://cgit.freedesktop.org/gstreamer/gstreamer/diff/?id=2243adffa128c6f508b0926ee00bfb1b18fead5e
>> > _______________________________________________
>> > gstreamer-commits mailing list
>> > gstreamer-commits at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-commits
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> --
> Jos?
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 3 May 2011 00:21:42 -0300
> From: Lucas Alberto <lucasa at gmail.com>
> Subject: Re: How to remove a source of a Adder while playing?
> To: gstreamer-devel at lists.freedesktop.org
> Cc: chengmo03013106 at gmail.com, weiqinbo at gmail.com
> Message-ID: <BANLkTineUYhYe3rr-GTWfqVR+UViPdM7_A at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi!
> See this code:
> https://github.com/lucasa/livemixer/blob/master/src/LiveMixer.java
> It add/remove inputs to/from adder while playing.
>
> I saw the solution here:
> http://stackoverflow.com/questions/3899666/adding-and-removing-audio-sources-to-from-gstreamer-pipeline-on-the-go
>
> Lucas Alberto
>
>
>
>> ------------------------------
>>
>> Message: 4
>> Date: Fri, 29 Apr 2011 14:05:01 +0800
>> From: toto <weiqinbo at gmail.com>
>> Subject: Re: How to remove a source of a Adder while playing?
>> To: gstreamer-devel at lists.freedesktop.org
>> Message-ID: <1304057101.5079.6.camel at toto-desktop>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> hi, lucasa,
>> I used adder in my application and i can remove source element
>> dynamically by unlink and release-request-pad method.
>> But, i can not add the removed element to adder again.
>> Do you have any idea?
>> Thanks a lot.
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110503/31e32ae2/attachment.htm>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 3 May 2011 13:07:57 +0200
> From: Maarten Bosmans <mkbosmans at gmail.com>
> Subject: Re: cross-compiling and `orc.m4`
> To: gstreamer-devel at lists.freedesktop.org
> Message-ID: <BANLkTi=mQ2Xify25u_Spem+ABJgPxM0LKw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2011/3/19 David Schleef <ds at entropywave.com>:
>> On Fri, Mar 11, 2011 at 01:38:28AM +0100, Paul Menzel wrote:
>>> Dear orcc folks,
>>>
>>>
>>> using OpenEmbedded [1] trying to cross-compile GStreamer plug-ins (or
>>> PulseAudio from git master), which includes `orc.m4`, `Makefile` has to be
>>> adapted as noted in `gst-plugins.inc` [2].
>>>
>>> ? ? ? ? # orc.m4 calls pkg-config ----variable=orcc orc-0.4 to get the path to orcc,
>>> ? ? ? ? # resulting in /usr/bin/orcc. Force it to use the staged orcc.
>>> ? ? ? ? do_configure_append() {
>>> ? ? ? ? ? ? ? for i in $(find ${S} -name "Makefile") ; do
>>> ? ? ? ? ? ? ? ? ? ? ? sed -i -e s:${bindir}/orcc:${STAGING_BINDIR_NATIVE}/orcc:g $i
>>> ? ? ? ? ? ? ? done
>>> ? ? ? ? }
>>
>> Use 'ORCC=/usr/bin/orcc ./configure' to override ORCC.
>
> It would be nice to automatically detect when pkg-config returns a
> non-functional orcc. The attached patch for orc.m4 does this and uses
> the first orcc from $PATH when cross-compiling.
>
> Should be enough to automatically do the right thing for Paul's and my
> situation. Of course it is still overridable by setting ORCC
> explicitly.
>
> How about maintaining the m4 orc detection macro in the orc tree? Then
> there is a canonical location for other projects (gstreamer,
> pulseaudio) to look for updates of the file.
> I'd say only the ORC_CHECK part should move to the orc tree and
> ORC_OUTPUT can stay in the gstreamer tree, as we for pulseaudio do not
> use ORC_OUPUT.
>
>> This is the correct way of doing things, because the tools involved
>> (pkg-config and autoconf) don't understand the concept of building
>> a native tool when cross-compiling.
>>
>> Alternately, a build system could modify the orc-0.4.pc file when
>> cross-building orc, so that the orcc variable is set to the tool in
>> the staging directory.
>>
>> David
>
> Maarten
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: gstreamer-orc-m4.patch
> Type: application/octet-stream
> Size: 1151 bytes
> Desc: not available
> URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110503/3679d4fd/attachment.obj>
>
> ------------------------------
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> End of gstreamer-devel Digest, Vol 4, Issue 5
> *********************************************
>
More information about the gstreamer-devel
mailing list