audiotestsrc vs. multifilesrc
floe at butterbrot.org
Fri Jan 14 12:02:21 UTC 2022
thank you, that was very helpful - in my case, adding "identity sync=true" after
wavparse was all that I needed to make it work.
On 13/01/2022 14:17, Marianna Smidth Buschle wrote:
> I strongly believe I have experienced similar issues, but related to
> images/video instead of audio.
> Your basic problem is that 'multifilesrc' is not a live source, while you use
> the 'audiotestsrc' as live.
> That basically means that while a live source will produce buffers based on the
> configured timing (from CAPS), the non-live source will produce buffers as fast
> as possible (or as fast as the downstream elements tell it to).
> You can try checking the difference by doing:
> audiotestsrc is-live=true wave=ticks ! audio/x-raw,format=S16LE,rate=48000,channels=1 ! autoaudiosink sync=true
> audiotestsrc is-live=true wave=ticks ! audio/x-raw,format=S16LE,rate=48000,channels=1 ! autoaudiosink sync=false
> For the live source you shouldn't see any difference.
> But I expect that you will see for the non-live, depending on using
> 'autoaudiosink sync=true' or 'autoaudiosink sync=false'
> multifilesrc do-timestamp=true loop=true location=count.wav ! wavparse ignore-length=1 ! audio/x-raw,format=S16LE,rate=48000,channels=1 ! autoaudiosink sync=false
> Now, the way I managed to have file sources working as "live sources" for me was
> by adding either a 'identity sync=true' or 'clocksync' to the pipeline.
> Something like:
> multifilesrc do-timestamp=true loop=true location=count.wav ! wavparse ignore-length=1 ! audio/x-raw,format=S16LE,rate=48000,channels=1 ! clocksync ! autoaudiosink sync=false
> Now, I do remember some issues with 'multifilesrc', so I would recommend trying
> also with 'filesrc' instead.
> And I was using H264 streams packed to MPEG-TS, in this case it would only work
> after the demuxer:
> gst-launch-1.0 filesrc location=/tmp/test1.ts ! tsdemux name=demux :
> queue ! identity sync=true ! h264parse ! avdec_h264 qos=false ! videoconvert !
> demux. : queue ! identity sync=true ! decodebin : audioconvert ! autoaudiosink
> Note that I haven't tested any of the pipelines besides this last one, which
> comes from my own project...
> Best Regards
> Marianna S. Buschle
> On 13.01.2022 13.00, gstreamer-devel-request at lists.freedesktop.org wrote:
>> Hello everyone,
>> I'm having an issue here that's probably very simple, but I can't see what's wrong.
>> I've been using the following audio source for testing in my larger WebRTC pipeline:
>> audiotestsrc is-live=true wave=ticks !
>> audio/x-raw,format=S16LE,rate=48000,channels=1 ! tee allow-not-linked=true
>> Now I've tried to replace it with an audiofile of a voice counting (to estimate
>> delay etc.):
>> multifilesrc do-timestamp=true loop=true location=count.wav ! wavparse
>> ignore-length=1 ! audio/x-raw,format=S16LE,rate=48000,channels=1 ! tee
>> allow-not-linked=true name=audiotestsrc
>> The audiofile does have S16LE/48kHz/mono, so there shouldn't be any format
>> issues. Both variants work when I run them in gst-launch-1.0 and append an
>> autoaudiosink at the end; I can even replicate the encoder pipeline by appending
>> "... ! queue ! opusenc ! rtpopuspay ! queue max-size-time=100000000 !
>> rtpopusdepay ! opusdec ! autoaudiosink" and it still works for both of them.
>> However, when I connect the encoder output to webrtcbin within my larger
>> pipeline, then the multifilesrc seems to never start streaming. Caps negotiation
>> and WebRTC SDP negotiation both complete and seem to be fine, but I'm never
>> actually getting an audiostream unless I keep using audiotestsrc (or e.g.
>> alsasrc/pulsesrc, those work as well).
>> For the curious, audiofile in question is here:
>> Any suggestions?
>> Thanks and best regards, Florian
> Best regards / Med venlig hilsen
> “Marianna Smidth Buschle”
SENT FROM MY DEC VT50 TERMINAL
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: OpenPGP digital signature
More information about the gstreamer-devel