<div dir="ltr"><div dir="ltr">Hi Mathieu,<div><br></div><div>Thanks again for your replies.</div><div>As uridecodebin already includes queues (if I read correctly), I tried adding A/V queues (with default values) at the end, as follows : </div><div><font face="monospace">+---------------------------------------------------------------------------------------+<br>| uridecodebin.audio ->- audioconvert ->- audioresample </font><span style="font-family:monospace">->- queue </span><span style="font-family:monospace">->-</span><span style="font-family:monospace"> </span><font face="monospace">webrtcssink.audio |</font></div><div><font face="monospace">| uridecodebin.video ----->----- videoconvert ------>------ </font><span style="font-family:monospace">queue </span><span style="font-family:monospace">->-</span><span style="font-family:monospace"> </span><span style="font-family:monospace">webrtcssink.video |</span></div><div><font face="monospace">+---------------------------------------------------------------------------------------+</font><br></div></div><div class="gmail_quote"><div class="gmail_attr">But unfortunately it did not bring any audible improvement.</div><div class="gmail_attr">I also tried adding another one between converting and resampling audio, as follows:</div><div class="gmail_attr"><div dir="ltr"><div><font face="monospace">+-------------------------------------------------------------------------------------------------+<br>| uridecodebin.audio ->- audioconvert</font><font face="monospace"> </font><span style="font-family:monospace">->- queue </span><span style="font-family:monospace">->-</span><span style="font-family:monospace"> </span><font face="monospace">audioresample </font><span style="font-family:monospace">->- queue </span><span style="font-family:monospace">->-</span><span style="font-family:monospace"> </span><font face="monospace">webrtcssink.audio |</font></div><div><font face="monospace">| uridecodebin.video -------->-------- videoconvert -------->-------- </font><span style="font-family:monospace">queue </span><span style="font-family:monospace">->-</span><span style="font-family:monospace"> </span><span style="font-family:monospace">webrtcssink.video |</span></div><div><font face="monospace">+-------------------------------------------------------------------------------------------------+</font><br></div></div><div class="gmail_quote"><div class="gmail_attr">To no avail :-(</div><div class="gmail_attr"><br></div></div></div><div class="gmail_attr">But maybe that wasn't what you meant ?<br></div><div class="gmail_attr"><br></div><div class="gmail_attr">KR, </div><div class="gmail_attr"><br></div><div class="gmail_attr">Vincent</div><div class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Mon, Nov 20, 2023 at 3:05 PM Mathieu Duponchelle <<a href="mailto:mathieu@centricular.com" target="_blank">mathieu@centricular.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Have you tried using queues to smooth things out between the<br>
uridecodebin and webrtcsink?<br>
<br>
On Fri, 2023-11-17 at 01:13 +0100, Vincent Deconinck via gstreamer-<br>
devel wrote:<br>
> Hi,<br>
> <br>
> Thanks for all the insightful answers. The log suggestion and the<br>
> audio frame timing issue triggered the idea of a few more tests.<br>
> <br>
> Here are the tests I did today:<br>
> 1. (set logging with GST_DEBUG=5). Ran the gstreamer server and the<br>
> browser with "choppy audio". The log is 350+MB and file writing<br>
> clearly impacts the playback (audio choppiness is increased and video<br>
> becomes choppy too). AFAICT however, the log shows no ERROR until the<br>
> end of the video ("pause task, reason: Flushing"). The zipped log is<br>
> available on <a href="https://we.tl/t-n3kLKluEXE" rel="noreferrer" target="_blank">https://we.tl/t-n3kLKluEXE</a><br>
> 2. (still logging with GST_DEBUG=5) Changed the pipeline to only use<br>
> the audio from the webm trailer video file, and used a videotestsrc<br>
> as the video source => audio is still very choppy<br>
> 3. (still logging with GST_DEBUG=5) Extracted the audio to a plain<br>
> uncompressed wav file (obtained with "ffmpeg -i sintel_trailer-<br>
> 480p.webm sintel_trailer-480p.wav") and used this as the audio source<br>
> and the videotestsrc as the video source => audio is still very<br>
> choppy<br>
> 4. (no logging from here on) Same test: WAV file as the audio source<br>
> and the videotestsrc as the video source => audio is perfect !<br>
> 5. Back to using the webm file as the audio source and the<br>
> videotestsrc as the video source => audio is choppy<br>
> 6. Converted the source file (vp8+vorbis) to mpeg4 (h264+aac) with<br>
> "ffmpeg -i sintel_trailer-480p.webm sintel_trailer-480p.mp4" and used<br>
> this as the audio source and the videotestsrc as the video source =><br>
> audio is "almost" perfect (I can still hear a "drop" in the second<br>
> drum at 00:16, which is not present when playing the mp4 file locally<br>
> with VLC).<br>
> 7. Used the mp4 as source for both video and audio => Fails with<br>
> "Error received from element wsink: There is no codec present that<br>
> can handle the stream's type.". Seems h264 video is not recognized ?<br>
> 8. Converted the source file (vp8+vorbis) to a ts (mpeg2video+ac3)<br>
> with "ffmpeg -i sintel_trailer-480p.webm -acodec ac3 -vcodec<br>
> mpeg2video sintel_trailer-480p.ts" and used it for both video and<br>
> audio => Fails with "There is no codec present that can handle the<br>
> stream's type". Seems mpeg2video is also not recognized ?<br>
> 9. Baked an alternate webm file using opus instead of vorbis with<br>
> "ffmpeg -i sintel_trailer-480p.webm -strict -2 -acodec opus -vcodec<br>
> copy sintel_trailer-480p_opus.webm" => audio/video is perfect !<br>
> <br>
> OK. What did I learn ?<br>
> - a lack of resources (e.g. heavy logging) causes choppiness. My PC<br>
> is quite good though (core i9 3.6GHz 32GB w/ GeForce RTX 2060) but<br>
> maybe logging chokes gsteamer.<br>
> Regarding audio codecs :<br>
> - Vorbis causes atrocious choppiness.<br>
> - AAC is almost OK<br>
> - Wav and Opus are perfect<br>
> Regarding video codecs:<br>
> - It seems this pipeline only accepts vp8 as input<br>
> <br>
> Questions: <br>
> My source files being either mpeg4 (with aac or ac3 audio) or even<br>
> MXF (and conversion beforehand not being an option),<br>
> - How can I convert the videos on the fly ? <br>
> - Isn't vconvert meant to perform the conversion if required ?<br>
> <br>
> Sorry again for the newbie questions...<br>
> <br>
> Kind regards,<br>
> <br>
> Vincent<br>
> <br>
> On Thu, Nov 16, 2023 at 7:07 PM cfd new <<a href="mailto:newcfd@yahoo.com" target="_blank">newcfd@yahoo.com</a>> wrote:<br>
> >  <br>
> > Thank you so much for your detailed mail. Very nice!<br>
> > <br>
> >     Joe<br>
> > <br>
> >  <br>
> >  <br>
> >  <br>
> >  On Thursday, November 16, 2023, 01:00:44 p.m. EST, cfd new via<br>
> > gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>> wrote: <br>
> >  <br>
> > <br>
> >  <br>
> > <br>
> >  <br>
> >  <br>
> > Hi, Philipp, <br>
> > <br>
> >    very interested in your code. I got the following message when I<br>
> > stream a live video to youtube. Maybe it is related to your case.<br>
> > <br>
> >    Joe<br>
> > 0:03:35.140304346 21323 0x7f1fa004c240 WARN           audioresample<br>
> > gstaudioresample.c:732:gst_audio_resample_check_discont:<audioresam<br>
> > ple1> encountered timestamp discontinuity of 639 samples =<br>
> > 0:00:00.039937500<br>
> > 0:03:35.141001930 21323 0x7f1fa004c240 WARN           audioresample<br>
> > gstaudioresample.c:732:gst_audio_resample_check_discont:<audioresam<br>
> > ple1> encountered timestamp discontinuity of 639 samples =<br>
> > 0:00:00.039937500<br>
> > 0:03:35.141314636 21323 0x7f1fa004c240 WARN           audioresample<br>
> > gstaudioresample.c:732:gst_audio_resample_check_discont:<audioresam<br>
> > ple1> encountered timestamp discontinuity of 639 samples =<br>
> > 0:00:00.039937500<br>
> > <br>
> >  <br>
> >  <br>
> >  <br>
> >  On Thursday, November 16, 2023, 06:35:55 a.m. EST, Philipp B via<br>
> > gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>> wrote: <br>
> >  <br>
> > <br>
> >  <br>
> > <br>
> >  <br>
> > Hi,<br>
> > <br>
> > [dislaimer: I didnt work with gstreamer for some time, my<br>
> > terminology<br>
> > might be a bit rusty]<br>
> > <br>
> > I also had audio issues when streaming video files over webrtc, and<br>
> > judging by your video, it could be the same issue you face.<br>
> > <br>
> > For me it turned out to be small rounding errors in the audio frame<br>
> > timestamps. Due to the realtime nature, browsers playing webrtc<br>
> > audio<br>
> > are not aiming for a perfect smooth playback, but rather for<br>
> > perfect<br>
> > realtime. Small deviations in timestamps instantly lead to the<br>
> > browser<br>
> > inserting small pieces of silence, or dropping a few ms of audio.<br>
> > <br>
> > The most obvious effect was the volume being way lower than it<br>
> > should<br>
> > be. This was caused by the player/browser constantly fading<br>
> > segments<br>
> > in and out, to overlap them with the next one, or with silence.<br>
> > Also,<br>
> > I had similar distortion artifacts than you have.<br>
> > <br>
> > To be clear, my issue seemed to be related to transmission of<br>
> > non-live, pre-encoded video only. WebRTC is made for live<br>
> > transmissions, where audio frame timestamps are directly related to<br>
> > the wall clock time at which a segment has been recorded. In<br>
> > contrast,<br>
> > a non-live video file typically has a stream of audio segments,<br>
> > which<br>
> > are expected to be played back without gaps, even when there are<br>
> > small<br>
> > gaps according to the time stamps.<br>
> > <br>
> > What happens if you increase the audio frame size? In my case, this<br>
> > was improving the situation dramatically, but not fully fixing it.<br>
> > <br>
> > In the end, I got this solved by "smoothing" audio time stamps. I<br>
> > wrote my own gstreamer element, that kept an estimation of the next<br>
> > frames timestamp, based on the last frame. In case, there is a<br>
> > small<br>
> > deviation (e.g. below 5 ms), the frames timestamp will be changed<br>
> > to<br>
> > that of the estimation. I can provide the code of that element in<br>
> > case<br>
> > your interested.<br>
> > <br>
> > Philipp<br>
> > <br>
> > Am Mi., 15. Nov. 2023 um 23:39 Uhr schrieb Vincent Deconinck via<br>
> > gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>>:<br>
> > <br>
> > > <br>
> > > Hi,<br>
> > > <br>
> > > I made some progress in my quest to stream video files to a<br>
> > > browser using webrtcssink, but audio is not OK. I built the<br>
> > > following pipeline:<br>
> > > +----------------------------------------------------------------<br>
> > > -------------+<br>
> > > | uridecodebin.audio ->- audioconvert ->- audioresample ->-<br>
> > > webrtcssink.audio |<br>
> > > | uridecodebin.video ----->----- videoconvert ------>------<br>
> > > webrtcssink.video |<br>
> > > +----------------------------------------------------------------<br>
> > > -------------+<br>
> > > <br>
> > > The webrtcsink pads are statically linked, and the uridecodebin<br>
> > > pads are dynamically linked upon "pad_added" signal (as in<br>
> > > <a href="https://gstreamer.freedesktop.org/documentation/tutorials/basic/dynamic-pipelines.html" rel="noreferrer" target="_blank">https://gstreamer.freedesktop.org/documentation/tutorials/basic/dynamic-pipelines.html</a><br>
> > > ).<br>
> > > <br>
> > > Problem: The video looks OK in the browser, but the audio is<br>
> > > choppy. A quick and dirty (sorry) video tells a thousand words:<br>
> > > <a href="https://youtu.be/1EbPHLZvVLc?t=27" rel="noreferrer" target="_blank">https://youtu.be/1EbPHLZvVLc?t=27</a><br>
> > > <br>
> > > (using signalling server, JS API and gstreamer built 2 days ago<br>
> > > from git HEAD)<br>
> > > <br>
> > > I was first using the http URI to the source video but I also<br>
> > > tried using a local copy of the file, to no avail.<br>
> > > <br>
> > > Any idea what could be wrong ? Or an idea how I could track down<br>
> > > that issue ?<br>
> > > <br>
> > > Kind regards,<br>
> > > <br>
> > > Vincent<br>
> >  <br>
> >  <br>
> >  <br>
> >  <br>
</blockquote></div></div>