Fixed length GOPs using x264enc gstreamer plugin

Omkiran Sharma omkiran.for.wiki at gmail.com
Fri Oct 28 07:44:36 PDT 2011


x264 library has a --no-scenecut option which you can pass in x264opts
properties

On Fri, Oct 28, 2011 at 12:30 AM, <
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: textoverlay silent property looks not well implemented
>      (Stefan Sauer)
>   2. Re: gstreamer: registry: add support for
>      GST_REGISTRY_REUSE_PLUGIN_SCANNER=no (Jan Schmidt)
>   3. Re: Get v4l2src width and height before pipeline runs?
>      (Edward Hervey)
>   4. what would happen if the time returned by gst_clock_get_time
>      decrease (chensheng duan)
>   5. Re: capturing mjpeg from ip-camera (Hans Maree)
>   6. Fixed length GOPs using x264enc gstreamer plugin (Deepika)
>   7. output a rtp theora stream into ogv file properly (athanase)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 27 Oct 2011 10:40:46 +0200
> From: Stefan Sauer <ensonic at hora-obscura.de>
> Subject: Re: textoverlay silent property looks not well implemented
> To: Discussion of the development of and with GStreamer
>        <gstreamer-devel at lists.freedesktop.org>
> Message-ID: <4EA9190E.3070708 at hora-obscura.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 10/27/2011 09:33 AM, bcxa sz wrote:
> > Hi Developers,
> >
> > The 'silent' property (to hide and display subtitle during playback)
> > of official gstreamer textoverlay is also not well implemented.
> >
> > In textoverlay gst_text_overlay_video_chain(), it just push pure video
> > data but without consuming the text data. Then
> > gst_text_overlay_text_chain() will blocked to waiting for the text
> > data consumed.
> >
> > For subtitle mixed with av in the same file, the demux will block at
> > the text demuxing since text data not consumed then will not demux any
> > followed audio and video data.
> >
> > best regards
> >
> > BCXA
> please file to bugzilla.
>
> Stefan
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 27 Oct 2011 19:54:38 +1100
> From: Jan Schmidt <thaytan at noraisin.net>
> Subject: Re: gstreamer: registry: add support for
>        GST_REGISTRY_REUSE_PLUGIN_SCANNER=no
> To: gstreamer-devel at lists.freedesktop.org
> Cc: Tim-Philipp M?ller <t.i.m at zen.co.uk>
> Message-ID: <1319705684.9856.7.camel at shorty>
> Content-Type: text/plain; charset="UTF-8"
>
> I'm not sure what the failure mode is when it runs into trouble on
> Android, but if it's just that a plugin fails to load once there are too
> many shared libs and stuff, then a solution might be to let the scanner
> die, and then re-launch the plugin scanner and check any plugin that
> crashes twice. At worst, plugins that actually crash get checked twice,
> at best you never need to re-spawn the plugin scanner.
>
> J.
>
> On Wed, 2011-10-26 at 03:20 -0700, Tim M?ller wrote:
> > Module: gstreamer
> > Branch: master
> > Commit: dd9f244f033ba3978d6ee26d9205d29fdd862d7c
> > URL:
> http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=dd9f244f033ba3978d6ee26d9205d29fdd862d7c
> >
> > Author: Tim-Philipp M?ller <tim.muller at collabora.co.uk>
> > Date:   Tue Oct 18 23:19:47 2011 +0100
> >
> > registry: add support for GST_REGISTRY_REUSE_PLUGIN_SCANNER=no
> >
> > This will make sure we spawn a new plugin scanner helper for each plugin
> > to be introspected, which helps with making sure we don't load too many
> > shared objects (libs, plugins) at the same time on systems where there
> > is a hard limit like on Android.
> >
> > A better version might re-use the scanner for up to N times, though
> > it's not clear whether that would actually improve things dramatically.
> >
> > https://bugzilla.gnome.org/show_bug.cgi?id=662091
> >
> > ---
> >
> >  gst/gstregistry.c |   13 +++++++++++++
> >  1 files changed, 13 insertions(+), 0 deletions(-)
> >
> > diff --git a/gst/gstregistry.c b/gst/gstregistry.c
> > index 56107c5..ddbb789 100644
> > --- a/gst/gstregistry.c
> > +++ b/gst/gstregistry.c
> > @@ -175,6 +175,8 @@ extern GList *_priv_gst_plugin_paths;
> >
> >  /* Set to TRUE when the registry cache should be disabled */
> >  gboolean _gst_disable_registry_cache = FALSE;
> > +
> > +static gboolean __registry_reuse_plugin_scanner = TRUE;
> >  #endif
> >
> >  /* Element signals and args */
> > @@ -1084,6 +1086,11 @@ gst_registry_scan_plugin_file
> (GstRegistryScanContext * context,
> >      changed = TRUE;
> >    }
> >
> > +  if (!__registry_reuse_plugin_scanner) {
> > +    clear_scan_context (context);
> > +    context->helper_state = REGISTRY_SCAN_HELPER_NOT_STARTED;
> > +  }
> > +
> >    return changed;
> >  }
> >
> > @@ -1616,6 +1623,12 @@ ensure_current_registry (GError ** error)
> >    }
> >
> >    if (do_update) {
> > +    const gchar *reuse_env;
> > +
> > +    if ((reuse_env = g_getenv ("GST_REGISTRY_REUSE_PLUGIN_SCANNER"))) {
> > +      /* do reuse for any value different from "no" */
> > +      __registry_reuse_plugin_scanner = (strcmp (reuse_env, "no") != 0);
> > +    }
> >      /* now check registry */
> >      GST_DEBUG ("Updating registry cache");
> >      scan_and_update_registry (default_registry, registry_file, TRUE,
> error);
> >
> > _______________________________________________
> > gstreamer-commits mailing list
> > gstreamer-commits at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-commits
>
> --
> Jan Schmidt <thaytan at noraisin.net>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 27 Oct 2011 11:22:25 +0200
> From: Edward Hervey <bilboed at gmail.com>
> Subject: Re: Get v4l2src width and height before pipeline runs?
> To: Discussion of the development of and with GStreamer
>        <gstreamer-devel at lists.freedesktop.org>
> Message-ID: <1319707345.17494.1.camel at deumeu>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
>  Caps negotiation is *always* done before any data passing happens.
>  i.e. your element's pad setcaps function will be called before any
> call to the chainfunction.
>
>  If you haven't implemented a pad setcaps function ... there's your
> problem :)
>
>    Edward
>
> On Wed, 2011-10-26 at 13:34 -0700, wally_bkg wrote:
> > Up to now I've been setting caps with a specific width and height needed
> for
> > our table driven image processing algorithm and using videoscale to force
> > the pipeline to that size (640x480) at the appsink.
> >
> > The algorithm's original author visited recently and his recollections
> and
> > insights have allowed me to remove that restriction.  This has exposed
> the
> > fact that I don't know how to get the width and height caps until the
> > pipeline is running, at which point its effectively too late.
> >
> > Is there a way to get the results of the caps negotiation before the
> > pipeline is running?
> >
> >
> >
> > --
> > View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/Get-v4l2src-width-and-height-before-pipeline-runs-tp3942212p3942212.html
> > Sent from the GStreamer-devel mailing list archive at Nabble.com.
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 27 Oct 2011 17:30:29 +0800
> From: chensheng duan <csduan2009 at gmail.com>
> Subject: what would happen if the time returned by gst_clock_get_time
>        decrease
> To: gstreamer-devel at lists.freedesktop.org
> Message-ID:
>        <CAEVJB7M-UFcjBeGNL-YB_p19oAkAzY3NZ=nfjfTDx8VROcKQAw at mail.gmail.com
> >
> Content-Type: text/plain; charset="utf-8"
>
> hi there:
>         we came cross a problem that we need to roll back the time returned
> by the gst_clock_get_time under some situation. the background list as
> below:
>         we run gstreamer on our arm board, and our audio hardware decode
> and render run as 1x normal speed all the time while video hardware decode
> and render can run as much faster as it can(maybe several times than 1x
> speed), so the problem is , if sometimes video data delay when recieved by
> decode , just drop the delayed buffer in render, and video decode can push
> the following buffer asap, but if audio data delay when recieved by audio
> decode , no matter drop or not in render , the pts cannot catch up with the
> correct render time since if audio data late 2s when in decode , and audio
> decode run as 1x speed, then it will late permanently 2s.
>         so we decide to use audiosink to provide clock, the clock still is
> systime clock, but if we found audio late 2s for ex, we will return
> (current_sys_clock_time -2s) to make video delay for 2 seconds to make
> video
> wait for audio.  it will draw back pipeline clock ,  i dont know if it will
> cause some problems. and if you guys have some idea , plz give me some
> advices, thx in advance!
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20111027/4a9b745b/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 5
> Date: Thu, 27 Oct 2011 03:54:49 -0700 (PDT)
> From: Hans Maree <hans.maree at gmail.com>
> Subject: Re: capturing mjpeg from ip-camera
> To: gstreamer-devel at lists.freedesktop.org
> Message-ID: <1319712889278-3943932.post at n4.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Thanks for your reaction Mike,
>
> over the last week I did some more experimentation using your debug wrapper
> script (which is extremely usefull) and I got it to work:
>
>
> I found out however that the stream is not exactly one frame per second so
> I
> got some 'drift' in the frame timing. So I decided to use a matroska
> container instead since it supports variable frame rate:
>
>
> I'm sure if this solves the problem completely since I still tell gstreamer
> to use a framerate of 1fps, but it does seem to limit the drift to an
> exeptable level.
>
>
> Mike Mitchell wrote:
> >
> > For making multiple files as output look into multifilesink.
> >
> http://gstreamer-devel.966125.n4.nabble.com/How-to-capture-a-still-image-while-previewing-live-video-td3813993.html
> >
> I'm not sure this is what I am looking for since it seems that
> multifilesink
> does not create complete video files, but simply cuts the file in several
> bits, which makes sense since the matroskamux element is responsible for
> creating the file structure. I think that for now I will just restart the
> pipeline every ten minutes, changing the location of the filesink every
> time. Later I will try for a more elegant solution.
>
> Hans Maree
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/capturing-mjpeg-from-ip-camera-tp3913047p3943932.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 27 Oct 2011 19:28:06 +0800
> From: Deepika <deepika at cinemacraft.tv>
> Subject: Fixed length GOPs using x264enc gstreamer plugin
> To: gstreamer-devel at lists.freedesktop.org
> Message-ID: <4EA94046.1050403 at cinemacraft.tv>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> Is it possible to produce fixed length GOPS using the x264enc gstreamer
> plugin. There is only key_int_max property that can be configured , so I
> am not sure if it is possible. Any help/ confirmations will be highly
> appreciated.
>
> Thanks,
> Deepika
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 27 Oct 2011 06:40:27 -0700 (PDT)
> From: athanase <jean.inderchit at gmail.com>
> Subject: output a rtp theora stream into ogv file properly
> To: gstreamer-devel at lists.freedesktop.org
> Message-ID: <1319722827163-3944464.post at n4.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> I have a question about gstreamer. i made a streaming server using
> gst-rtsp-server. I'm trying to send camera capture to another machine (on
> the local network) and to parse it into an .ogv file.
>
> The transmission of the streaming works fine, and i'm able to parse the
> informations into the file; but i can't read it or use it with any
> application after this parsing. It seems that there are some information
> missing (probably in relation with the encoding technique, i don't really
> know much about it)
>
> Server side command (inside c++ code):
>
> ....
> gst_rtsp_media_factory_set_launch (factory, "( v4l2src device=/dev/video0 !
> videorate !
> video/x-raw-yuv,width=320,height=240,framerate=30/1 ! videoscale !
> ffmpegcolorspace !
> theoraenc ! rtptheorapay name=pay0 pt=96 )");
>
> gst_rtsp_media_factory_set_shared (factory, TRUE);
>
> /* attach the test factory to the /test url */
> gst_rtsp_media_mapping_add_factory (mapping, "/stream", factory);
> ....
>
>
> Client side command (terminal command) :
>
> gst-launch -v rtspsrc location=rtsp://192.168.0.115:8554/stream !
> rtptheoradepay name=pay0 ! oggmux ! filesink
> location=/home/jean/Desktop/stream.ogv
> Any help any kind of help is well appreciated !
>
> Jean
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/output-a-rtp-theora-stream-into-ogv-file-properly-tp3944464p3944464.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
>
> ------------------------------
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> End of gstreamer-devel Digest, Vol 9, Issue 80
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20111028/0f736d4e/attachment-0001.htm>


More information about the gstreamer-devel mailing list