On Thu, Nov 10, 2011 at 12:01 AM, Martin Storsjö <[email protected]> wrote: > On Wed, 9 Nov 2011, John Brooks wrote: > >> RTCP timestamps are only necessary to synchronize time between >> multiple streams. For a single stream, the RTP packet timestamp >> provides more reliable timing. As a result, single-stream RTP >> sessions should now have accurate and monotonic PTS. >> --- >> libavformat/rtpdec.c | 8 +++++--- >> 1 files changed, 5 insertions(+), 3 deletions(-) >> > > The patch in itself looks fine, although checking info via s->ic->nb_streams > is kinda ugly (but probably the most straightforward approach here). >
Agreed, but that was my conclusion as well. This is technically wrong if it's possible for the input context to have non-RTP streams too. > The question is whether others think is an acceptable thing to disable RTCP > based timestamps completely for this case. > Yes, and it is the correct thing. The RTCP timestamp provides synchronization, and the RTP timestamp provides timing. When we have nothing to synchronize with, it is wrong to alter timing. The RTCP timestamp provides no additional reliable information about timing. I still plan to improve the RTCP calculation somehow, but it cannot be more accurate than this. > On top of my head, one problem with this is that the RTP based timestamps > have a kinda limited range, so the timestamps will wrap around relatively > quickly (unless we unwrap them by adding up the differences), which the RTCP > based calculation avoided. (A quick calculation says it will wrap around > within 13 hours with 90kHz based timing as for MPEG video.) > Excellent point; this is true now for any stream that doesn't get RTCP SRs. It should be unwrapped; do you want to do that, or should I? Thanks - John _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
