|
|
x264 library has a --no-scenecut option which you can pass in x264opts properties On Fri, Oct 28, 2011 at 12:30 AM, <[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: 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 <[hidden email]>
Subject: Re: textoverlay silent property looks not well implemented
To: Discussion of the development of and with GStreamer
<[hidden email]>
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: Re: gstreamer: registry: add support for
GST_REGISTRY_REUSE_PLUGIN_SCANNER=no
To: [hidden email]
Cc: Tim-Philipp M?ller <[hidden email]>
Message-ID: <1319705684.9856.7.camel@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 <[hidden email]>
> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-commits
--
Jan Schmidt <[hidden email]>
------------------------------
Message: 3
Date: Thu, 27 Oct 2011 11:22:25 +0200
From: Edward Hervey <[hidden email]>
Subject: Re: Get v4l2src width and height before pipeline runs?
To: Discussion of the development of and with GStreamer
<[hidden email]>
Message-ID: <1319707345.17494.1.camel@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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
------------------------------
Message: 4
Date: Thu, 27 Oct 2011 17:30:29 +0800
From: chensheng duan <[hidden email]>
Subject: what would happen if the time returned by gst_clock_get_time
decrease
To: [hidden email]
Message-ID:
<CAEVJB7M-UFcjBeGNL-YB_p19oAkAzY3NZ=[hidden email]>
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 <[hidden email]>
Subject: Re: capturing mjpeg from ip-camera
To: [hidden email]
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: Fixed length GOPs using x264enc gstreamer plugin
To: [hidden email]
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: output a rtp theora stream into ogv file properly
To: [hidden email]
Message-ID: <[hidden email]>
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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
End of gstreamer-devel Digest, Vol 9, Issue 80
**********************************************
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
|
Locked
