Re: gstreamer-devel Digest, Vol 4, Issue 5

[Mihai Stoica]

On Tue, May 3, 2011 at 2:07 PM,
<[hidden email]> wrote:

> Send gstreamer-devel mailing list submissions to
>        [hidden email]
>
> 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
>        [hidden email]
>
> You can reach the person managing the list at
>        [hidden email]
>
> 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 <[hidden email]>
> Subject: Re: Reading of GST tags with explicit pipeline and not
>        decodebin/playbin
> To: Discussion of the development of and with GStreamer
>        <[hidden email]>
> Cc: Mihai Stoica <[hidden email]>
> Message-ID: <[hidden email]>
> 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
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 2 May 2011 15:12:37 -0400
> From: Karen Schoener <[hidden email]>
> Subject: Should h264parse limit the max PPS id to 31 or 255?
> To: [hidden email]
> Message-ID: <[hidden email]>
> 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 <[hidden email]>
> Subject: Re: [0.11] gstreamer: event: add sticky flags to events
> To: [hidden email]
> Cc: Wim Taymans <[hidden email]>,
>        [hidden email]
> Message-ID: <[hidden email]>
> 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 <[hidden email]>
>> 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
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-commits
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 02 May 2011 18:24:40 -0400
> From: Jos? Alburquerque <[hidden email]>
> Subject: Re: [0.11] gstreamer: event: add sticky flags to events
> To: Discussion of the development of and with GStreamer
>        <[hidden email]>
> Cc: Wim Taymans <[hidden email]>, [hidden email],
>        [hidden email]
> Message-ID: <1304375080.8690.14.camel@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 <[hidden email]>
>> > 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
>> > [hidden email]
>> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-commits
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> --
> Jos?
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 3 May 2011 00:21:42 -0300
> From: Lucas Alberto <[hidden email]>
> Subject: Re: How to remove a source of a Adder while playing?
> To: [hidden email]
> Cc: [hidden email], [hidden email]
> Message-ID: <[hidden email]>
> 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 <[hidden email]>
>> Subject: Re: How to remove a source of a Adder while playing?
>> To: [hidden email]
>> Message-ID: <1304057101.5079.6.camel@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 <[hidden email]>
> Subject: Re: cross-compiling and `orc.m4`
> To: [hidden email]
> Message-ID: <BANLkTi=[hidden email]>
> Content-Type: text/plain; charset="utf-8"
>
> 2011/3/19 David Schleef <[hidden email]>:
>> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> End of gstreamer-devel Digest, Vol 4, Issue 5
> *********************************************
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel