On 11/22/2013 10:22 AM, Holger Hans Peter Freyther wrote:
On Fri, Nov 22, 2013 at 09:59:10AM +0100, Jacob Erlbeck wrote:
We can, but then I would like to put all of the above into the rtp_end structure.
sure.
Ok, then I'll refactor it this way.
Currently (with and without the patch) the packet is only patched after SSRC changes.
It was my understanding that the TS issue we were seing also appeared without a change in the SSRC? In case this is something I asked you to do after this patch we can postpone this discussion.
We've settled to just add counters and not to fix the timing for streams with a constant SSRC yet. So I'd rather put that feature into another commit after we've decided on the concept.
just based on heuristics and may fail theoretically.
SCNR: And in theory ip.access should be able to create working software with the capital they received. ;)
And the audio source should deliver non-broken audio streams either.
I would like to understand if the TS problem only occurs when the TS is changing or if the ts_delta issue is only introduced by the patching I do.
The TS problem in question only occured within streams of a singly SSRC and are thus not fixed by the patch (but detected).
I've only fixed the SSRC patching because I didn't want the osmo MGW/NAT to introduce the same kind of errors we are getting from the other audio source.
Jacob