Capturing and encoding live video and audio: AMD FX(tm)-8350 Eight-Core Processor not fast enough?

Rodrigo Severo rodrigo at fabricadeideias.com
Thu Dec 21 20:37:49 UTC 2017


2017-12-21 16:48 GMT-02:00 Nicolas Dufresne <nicolas at ndufresne.ca>:

> Le jeudi 21 décembre 2017 à 15:35 -0200, Rodrigo Severo a écrit :
> > gst-launch-1.0 v4l2src device=/dev/video0 norm=45056 ! queue !
> > videoconvert ! videoscale ! videorate ! 'video/x-raw, width=640,
> > height=400, framerate=15/1, format=I420' ! x264enc ! h264parse !
> > stream. pulsesrc device="alsa_input.usb-
> > Hauppauge_Hauppauge_Device_0013745411-01.analog-stereo" ! queue !
> > audioconvert ! audioresample ! 'audio/x-raw, channels=2, rate=48000'
> > ! lamemp3enc ! mpegaudioparse ! stream. mpegtsmux name=stream ! queue
> > ! filesink location=/home/rodrigo/temp/test.mpeg
> >
> > To my surprise I get several messages like:
> >
> > Setting pipeline to PAUSED ...
> > Pipeline is live and does not need PREROLL ...
> > Setting pipeline to PLAYING ...
> > New clock: GstPulseSrcClock
> > Redistribute latency...
> > Redistribute latency...
> > Redistribute latency...
> > WARNING: from element /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
> > Can't record audio fast enough
> > Additional debug info:
> > gstaudiobasesrc.c(847): gst_audio_base_src_create ():
> > /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
> > Dropped 125760 samples. This is most likely because downstream can't
> > keep up and is consuming samples too slowly.
> >
> > All messages from the warning to the "too slowly" are repeated all
> > the time.
> >
> > My first surprise: I believe an eight core processor should be much
> > more than enough to do such a job without problems but apparently it
> > isn't.
> >
> > My second surprise,: it's the _audio_ that's being too slowly
> > processed, not the video.
> >
> > In reality I believe I'm doing something wrong. Can someone help me
> > find what it is?
> >
> > BTW, I'm using GStreamer 1.12.3 on Ubuntu 17.10.
>
> It's propably a buffering issue. Disable bytes size limited on your
> queus, maybe that will fix it. Note that x264enc in default
> configuration is designed of offline encoding. Just retry and
> tune=zerolatency you'll see a large difference.
>

Yes, it seems to work much  better.


Thanks,

Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20171221/63fa62d8/attachment.html>


More information about the gstreamer-devel mailing list