Such an easy question

[James]

> On 18 Aug 2021, at 7:21 am, James via gstreamer-devel <gstreamer-devel at lists.freedesktop.org> wrote:
> 
> On 17 Aug 2021, at 5:25 am, Yu You via gstreamer-devel <gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>> wrote:
>> 
>> 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 <mailto: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
> 
> 
> OK lots of testing: here are some answers since the irony of the title must intrigue
> 
> First I wrote my recording code as a daemon (to sever all links to the app)
> 
> now on an clean system dvrRecord always works
> 
> With QT app running dvrRecord always fails
> 
> With a clean system dvrRecord then App works and continues working.
> 
> after App dvrRecord always works
> 
> The only way (there may be others I don't see) that I see the App having on dvrRecord is address in memory that is being used, but by magic smoke every process has memory from 0..NNNN no matter where in physical memory the process resides. The obvious question: I repeat the results on completely different hardware.
> 
> The time to fail is always 26 secs into the recording:
> soundsoundsound<click>0.5secsound  0.5sec_pause 0.5secsound 0.5sec_pause . . .


Oh Thai island he mentioned quite stridently!!! (that is a polite and subtle way of swearing)
I changed distro. I had been using Suse 15.2 and 15.3 to lubuntu 20.04 and all problems wafted away.
Sound and video are good and clean !!
I'm curious and will try to hunt down. I'll start building from src
James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210818/31f81b3d/attachment.htm>