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