Workaround for negative timestamp misinterpretation #64
Conversation
|
Thank you, @PyvesB |
|
@mondain do you have any timeline on when the next Red 5 milestone will be published? It would be nice to have this easily available as part of a Maven release. Thanks in advance! |
|
@mondain I noticed your recent 1.0.10-M10 release, however, it does not seem to contain the changes from this pull request. Is this to be expected? |
|
It wasn't intentionally skipped. |
|
It doesn't appear to be skipped, its in the codebase |
|
It is in the codebase, but I didn't see it there when I decompiled the 1.0.10-M10 source. Might this be related to merge commit 3faa0ae, which was pushed after the tagging done in ec51822? I'm wondering whether the release of red5-server-common was not performed from an outdated local copy, which then led to that merge commit. |
|
If its not in the decompile than you are probably correct; I'll get it in the release if I don't see any issues posted before January 1st. |
|
@mondain would it now be a good time to attempt a new release? 😃 |
|
I'll get one out in the next couple days; I have a SharedObject fix in as well. |
This pull request is related to disccusions on the red5-client repository, issue #44.
Unsigned timestamps between 231 and 232 -1, which Red5 misinterprets as negative signed integers between -231 and -1, are now rolled over to positive integers between 0 and 231 - 1. Instead of being discarded, RTMP messages with large timestamps are now sent downstream.
I have added some unit tests to cover this behaviour and have successfully tested the patch on our pre-production environment with a few different RTMP output destinations.