On 16 September 2013 11:37, Martin Storsjö <[email protected]> wrote: > On Mon, 16 Sep 2013, Josh Allmann wrote: > >> On 16 September 2013 10:00, Martin Storsjö <[email protected]> wrote: >>> >>> On Mon, 16 Sep 2013, Josh Allmann wrote: >>> >>>> Sending audio/video on the same channel leads to non-montonic >>>> timestamps when switching streams, so the RTMP timestamp delta >>>> is incorrectly written as a large unsigned number. >>> >>> >>> >>> Can you elaborate this a little further, I'm not sure I totally >>> understand >>> what you mean is happening. >>> >> >> RTMP packet timestamps are transmitted as a delta from the absolute >> timestamp of the previous packet in the same channel, and since >> audio/video streams aren't guaranteed to be monotonic relative to one >> another, we could have the following situation, with absolute >> timestamps: >> >> Video packet 1: Abs. timestamp 9 >> Audio packet 2: Abs. timestamp 10 > > > I assume you meant to have these two reversed? >
Er, yes. > >> uint32_t delta = 9 - 10 == 4294967295 > > > Ok, I see. > > What about this for the log message then: > > --- > Sending non-monotonic packets (e.g. when the audio and video streams are > monotonic within themselves but not muxed monotonically) will lead to > negative values the RTMP timestamp field (where timestamps are transmitted > only as deltas), and this delta can end up being incorrectly written as a > large unsigned number. > --- > Sounds good, will update the log message. > Is the fact that this ends up as a large unsigned number a bug in our RTMP > code that could be fixed as well, or are negative deltas something that > simply can't be done properly? > It is a bug in our RTMP code, and the fix in this case is not to send them on the same channel (which the Flash player never does as far as I've seen), although I suppose we could sanity check our own code, and print a log message if it happens under other conditions. Negative deltas should never happen. Josh _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
