Such an easy question

Yu You youyu.youyu at gmail.com
Mon Aug 16 21:25:59 UTC 2021


Did you try to get the raw frames from your webcam and use SW/HW H264
encoder to encode it for the muxer?

or allow "leacky" to the audio queue?

Yu

On Mon, 16 Aug 2021, 15:46 James via gstreamer-devel, <
gstreamer-devel at lists.freedesktop.org> wrote:

>
>
> Utter frustration:
>
> I have a script
>
> #! /bin/bash
>
> GST_DEBUG_DUMP_DOT_DIR=/home/jam/DOT gst-launch-1.0 $@ v4l2src
> device=/dev/video2 ! \
> video/x-h264,width=1920,height=1080,framerate=30/1 ! \
> h264parse ! \
> tee name=t \
> t. ! queue ! avdec_h264 ! xvimagesink sync=false \
> t. ! queue ! avdec_h264 ! xvimagesink sync=true \
> t. !  queue max-size-buffers=0 max-size-bytes=0 max-size-time=1000000000 !
> \
> mux. pulsesrc device=0 ! \
> queue ! \
> audioconvert ! \
> audioresample ! audio/x-raw, rate=16000 ! \
> queue ! \
> avenc_aac ! \
> queue ! \
> mux. mp4mux name=mux ! \
> filesink location=try9.mp4
>
> and a C version that behaves pretty much identically.
>
> Running the script on its own I have never seen it fail.
> My app is a QT5 gui. Running my app AND the script OR the compiled version
> by QProcess sometimes fails with the dreaded pulsesrc underflow, downstream
> consuming too slowly message.
> If it fails, it always fails until reboot.
>
> htop shows cpu usage of 10..30% 5..6G ram as cache and 0 swap being used.
> gnome-system-monitor shows no spikes in cpu usage.
> In desperation I swapped my 2 core i3 for a 4 core i7. Behaviour was the
> same.
>
> At other times it works for hours, many times in a row.
>
> What measurements might I make that may lead me to the problem.
>
> Needless to say if I leave the tee multiplex (and hence pulsesrc) out of
> the pipline then it never fails.
> I've tried mp4mux, qtmux and (by accident) mpegtsmux without any change
> being visible. I tried matuska but that fails everytime.
>
>
> This gets more outlandish:
>
> App->record: error after 25sec
>
> App->quit
>
> Script->record: all ok
>
> App->start
>
> Script stop
>
> App->record: all ok
>
> Repeatable, tried lots of times !!!
>
> Note
>
> App->record: error
>
> App->idle
>
> Script->record: error every time.
> cpu usage never goes over 40%
>
>
> On the chance someone recognises detail I post. This is playing a *bad*
> file:
>
> VLC error list
>
> [00007fd5accd5840] main decoder error: Could not convert timestamp
> 2456057878 for FFmpeg
> [00007fd5accd5840] main decoder error: Timestamp conversion failed (delay
> 1000000, buffering 100000, bound 9000000)
> [00007fd5accd5840] main decoder error: Could not convert timestamp
> 2456093211 for FFmpeg
>
> MPlayer error list
>
> libavformat file format detected.
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fa17f53b7a0]Protocol name not provided,
> cannot determine if input is local or a network protocol, buffers and
> access patterns cannot be configured optimally without knowing the protocol
> [lavf] stream 0: video (h264), -vid 0
> ==========================================================================
> AO: [pulse] 16000Hz 2ch floatle (4 bytes per sample)
> Starting playback...
> Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
>
> Possibly bad interleaving detected.
> Use -ni option if this causes playback issues and avoid or fix the program
> that created the file.
> A: 153.6 V: 163.6 A-V: -9.965 ct: -0.587   0/  0 53%  1%  0.2% 0 0
>
> Still trying to find out what happens when the system is in *bad* mode vs
> *good* mode
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210817/7ea53ad4/attachment.htm>


More information about the gstreamer-devel mailing list