Cant take an immediate screenshot image of static video from h264 rtp stream

anno domini genericgroupmail at gmail.com
Thu Sep 18 08:07:43 PDT 2014


Bonjour Nicolas!

Merci pour votre reponse!
Thanks so much for taking the time to answer.
I'm a little lost in that last part of your suggestion.
To make things a little quicker to debug i am now running everything on the
command line and i have removed the valve and the intra-refresh element.

As suspected i still see the long delay, here is my setup:

UDP STREAM SERVER (COMMAND LINE):
gst-launch -v -e v4l2src device=/dev/video1 norm=PAL ! videoscale !
video/x-raw-rgb, width=720, height=576, pixel-aspect-ratio=1/1 ! \
ffmpegcolorspace ! tee name=videoTee \
videoTee. ! queue ! x264enc tune="zerolatency" threads=1 ! rtph264pay
config-interval=2 ! udpsink port=8554 \
videoTee. ! queue ! x264enc tune="zerolatency" threads=1 ! rtph264pay
config-interval=2 ! udpsink port=8555

MONITOR CLIENT (COMMAND LINE):
gst-launch -v udpsrc port=8555 ! application/x-rtp, payload=96 !
rtph264depay ! ffdec_h264 ! xvimagesink

PNG CREATOR CLIENT PIPELINE (PYTHON):
udpsrc port=8554 ! application/x-rtp, payload=96 ! rtph264depay !
ffdec_h264 ! ffmpegcolorspace ! videoscale ! video/x-raw-rgb, bpp=24,
width=720, height=576, pixel-aspect-ratio=1/1 ! pngenc snapshot=true
compression-level=1 ! filesink location=/tmp/blah2.png

You are right that i am running on 0.10.
I'm not familiar with appsrc or pushing the buffer. Could you elaborate on
what you mean?

Merci Beaucoup!!!!!


On Thu, Sep 18, 2014 at 3:18 PM, Nicolas Dufresne <
nicolas.dufresne at collabora.com> wrote:

>
> Le 2014-09-18 09:34, anno domini a écrit :
>
>> gst-launch -v -e v4l2src device=/dev/video1 norm=PAL ! videoscale !
>> video/x-raw-rgb, width=720, height=576, pixel-aspect-ratio=1/1 !
>> ffmpegcolorspace ! tee name=videoTee \
>> videoTee. ! queue ! x264enc tune="zerolatency" threads=1
>> intra-refresh=true ! rtph264pay config-interval=2 ! udpsink port=8554
>>
>
> You may want to switch from intra-refresh toward periodic keyframe. The
> decoder is simply waiting until a full valid frame is available. Note this
> behaviour may have change if you move toward a recent GStreamer (you are
> using 0.10, which is unmaintained), you would endup with corrupted frame in
> your PNG (see avdec_h264 property output-corrupt). Also, note that the
> general valve approach is racy, and prevent you from taking a shot at a
> specific time since your decoder state is left undefined. Assuming you are
> always previewing this stream, you could set "enable-last-sample" on your
> display sink, and get the last-sample. On a second pipeline, using appsink,
> you could set the sample caps, push the buffer, send EOS, and you'd have a
> safe result instantly.
>
> Nicolas
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140918/bb50c421/attachment-0001.html>


More information about the gstreamer-devel mailing list