On Mon, 16 Sep 2013, Josh Allmann wrote:
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.
Hmm, ok. I remember seeing timestamps jumping backwards in RTMP streams in
certain odd circumstances, but I can't obviously reproduce it (IIRC it's a
few years since I saw it). And transmitting on two separate channels does
sound like a sensible to do either way.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
