<div>You might want to take a look at <a href="https://link.getmailspring.com/link/01368DED-CAB5-4AFC-96D6-72A979E45D74@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Fcentricular%2Fwebrtcsink&recipient=Z3N0cmVhbWVyLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZw%3D%3D" title="https://github.com/centricular/webrtcsink">https://github.com/centricular/webrtcsink</a> <span data-emoji-typing="true">:)</span></div><div class="gmail_quote_attribution">On Mar 12 2022, at 3:27 pm, Philipp B via gstreamer-devel <gstreamer-devel@lists.freedesktop.org> wrote:</div><blockquote><div><div>Hi all,</div><br><div>I am working on a somewhat experimental project to implement a "WebRTC</div><div>media player" with gstreamer. I am aiming to stream basically any A/V</div><div>media file over WebRTC at a quality, as near as possible to protocols</div><div>like MPD or HLS. Obviously, latency does not play a role here, but</div><div>there will be focus on trying to keep the playout in sync as much as</div><div>possible between the different peers being served in parallel.</div><br><div>I know, this is not exactly the target application for WebRTC, but</div><div>thats also what makes it interesting as an experimental project. I</div><div>already read about the playout delay WebRTC extension, which will be</div><div>worth looking at at some point, but I am far from being there.</div><br><div>At the moment, I am just trying to get the single peer stream with a</div><div>stable LAN connection as smooth as possible. I started with video-only</div><div>transmission, not caring too much about jitter, which was pretty</div><div>straight-forward. Now I am looking into audio, and it becomes far more</div><div>complicated.</div><br><div>For now, I am testing an audio-only transmisstion, but of course I</div><div>need to add synced video back later.</div><br><div>I learned that filesrc does not fulfill the "live/sync" requirement to</div><div>playout audio through rtpopuspay. There are some places on the web</div><div>mentioning that multifilesrc combined with "identity sync=true" is</div><div>suited to create a "fake live" media source.</div><br><div>I played with various variants, unsure where to put the identity</div><div>element, and the "do-timestamp" (and if its needed). As a reference,</div><div>this is my current pipeline which may contain some clutter, but its</div><div>about the best I got judging by audio quality:</div><br><div>multifilesrc location=... index=0 do-timestamp=1 ! queue ! decodebin !</div><div>queue ! identity sync=true ! queue ! audioconvert ! audioresample !</div><div>audio/x-raw,channels=2,rate=48000 ! opusenc bitrate=128000</div><div>frame-size=10 ! rtpopuspay pt=97 min-ptime=10000000 max-ptime=10000000</div><div>! webrtcbin</div><br><div>I chose frame-size=10, because the playback artifacts are worse with</div><div>smaller frame-sizes. So, chosing a rather small frame size, its easier</div><div>to spot them. Once I got the issues resolved, I plan to use</div><div>frame-size=60. min-ptime and max-ptime is something I found mentioned</div><div>somewhere. I thought it might help to reduce jitter in rtp timestamps,</div><div>but Im unsure about the effect.</div><br><div>Playing this in the browser (using music input), I can hear some</div><div>artifacts that are annoying but would be acceptable for voice as far</div><div>as I can tell. My current focus is to get this audio as good as</div><div>possible.</div><br><div>chrome://webrtc-internals tells me that samples are added and removed</div><div>to adjust timing, which explains the perceived artifacts pretty</div><div>accurately. Looking at the decoded RTP, I can see that rtp timestamps</div><div>are indeed slightly jittered. Ideally, I would expect the RTP</div><div>timestamp increments to be steadily at 480. (48kHz @ 10 ms frame</div><div>size).</div><br><div>This is now, where I could use some help....</div><br><div>What I expect to work (didnt test yet) is to use the datarate option</div><div>of the identity element on either raw or strictly CBR encoded audio,</div><div>to rewrite timestamps. However, then I will probably lose the original</div><div>timing information, and with it my option to keep the video in sync.</div><div>My guess is, in the end I need a typical media player logic to sync</div><div>everything on audio. But obvioulsy I am too lost to find the best way</div><div>to get there.</div><br><div>Thanks for reading so far, I hope I could make my issue clear. Any</div><div>pointers or comments would be useful. Some specific questions I could</div><div>think of:</div><br><div>- whats the easiest way to get this sorted? I mean, transmitting a av</div><div>media file's audio continuously, with no rtp timestamp jitter, and</div><div>with video in sync to it?</div><div>- In the above pipeline, where exactly is my rtp jitter coming from? I</div><div>assume "identity sync=true" is timing the throughput based on the</div><div>sources timestamps, and the jitter is basically a quantization</div><div>artifact because the original framesize does not match the re-encoded</div><div>framesize. Is this plausible? That would mean, the "sync/live" nature</div><div>of the source is not needed at all for timestamps, just for</div><div>transmission timing (correct?)</div><div>- Am I assuming correctly that rtpopuspay does not keep a context of</div><div>the stream, and is creating an rtp timestamp with no knowledge about</div><div>the last packets timestamp?</div><div>- Are there any handy debug level filters to trace consecutive packets</div><div>through the pipeline, regarding their timestamp?</div><div>- Is there a concise documentation, how many and which timestamps a</div><div>frame can actually have in gstreamer, where they are deduced from and</div><div>what they are generally used for (only in case there is anything else</div><div>except PTS and DTS - I am still in doubt if there is something third,</div><div>like MPEG2TS's PCR involved here...)</div><br><div>Thanks for any help!</div><div>Philipp</div></div></blockquote><img class="mailspring-open" alt="Sent from Mailspring" width="0" height="0" style="border:0; width:0; height:0;" src="https://link.getmailspring.com/open/01368DED-CAB5-4AFC-96D6-72A979E45D74@getmailspring.com?me=4936751b&recipient=Z3N0cmVhbWVyLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZw%3D%3D">