Ross Finlayson wrote:
if you're using our software to develop your client,
I can see how you might have gotten the impression that I was writing the client myself. When I said I had a client here, I meant it was sitting on the table over there to my right. :) It's a set-top box, much like an Amino, but far more powerful. I'm using your server to feed streams to it, for testing.
I'm being circumspect about the brand name and model because I don't imagine you have one, and it's not necessary that you go get one. This isn't about the quirks of Box X, because Box X is obeying the letter of the RFC, if perhaps not the spirit.
I've already asked the makers of Box X to make it send RTCP RR, but in the meantime, I have an fix. They know this, and that may prevent them from putting resources into this soon, or ever. I can maintain a private branch of the software with this fix in it, but of course that means an integration step every time you release a new version that has something I want.
Besides, there may be other clients out there that would benefit from this patch. The coming IPTV revolution is going to result in a whole lot of random STBs you've never heard of from companies you've never heard of coming on the market. The nature of things is that they'll have all sorts of odd behaviors, so even if this is the only box today that does this, it's probably not going to be the last.
your client already needs to *receive* RTCP "SR" packets,
I presume it does, since I don't see ICMP port unreachable coming back whenever I see an SR go by. I guess it could just be eating them.
I'm sending MPEG-2 transport streams, so I don't see that SR is necessary for A/V sync. The sync information is in the transport stream headers.
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
