On Thu, 10 Nov 2011, John Brooks wrote:
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.
These are fair points. I think I'm ok with this for now, but I'd like to
get Luca's opinion on it as well.
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?
I've got no particular need to do it myself, so feel free to make a patch
for it :-)
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
