[Live-devel] Live Streaming to Nokia/RealPlayer with DarwinInjector

[Peter Maersk-Moller]

Hi Erlend.

Sorry for being a bit off-topic, but I always had problems with
DSS reflecting live MPEG-4 streams (encoded with mp4live) and
streamed to various versions of the Realplayer. The audio was
off sync in the realplayer with 15-16 seconds.

Seriously tried to convince the Real folks
for 2 years now that they did a bad RTCP sync calculation, but
they never managed to alter/fix the player code. It always
ended with the Real folks saying that it works with their
3G encoder system. Can you problems and solution be related to this ?

(Tried earlier to relay though the Helix server with the same result)

Kind regards

Peter Maersk-Moller

-- 
+----------------------------------------------------------+
| Kabel-TV over Internettet   --   http://www.streamtv.dk/ |
+----------------------------------------------------------+

Simonsen, Erlend wrote:
> Just thought I'd let you know, after trying things more and more at
> random, I suddenly got my live AMR-NB & AMR-WB streams to play on the
> Nokia 6680 & 6630 RealPlayer today.
> 
> I'm not exactly sure why, but it seems like it might be a DSS problem in
> the QTSSReflector module. If I force liveMedias RTPSink to use a rtptime
> & rtpseq starting from 0, and disable those two parameters from the
> RTP-Info: header from DSS, it suddenly started to work for single-source
> streams. Multi-source streams bug out the player with a "Illegal Address
> Error" (roughly translated from Norwegian). If I try doing the same
> thing with the cvs version of DSS, it no longer works. 
> 
> I know it's quite a hack, but I did notice that Real Helix Server used 0
> as starting values, and it seems it did work around some other bugs at
> least.
> 
> I'm happy to say that it's not a liveMedia problem at least. :-)
> 
> One quick question, what remains to support packing multiple AMR frames
> in one RTP packet? AMRAudioRTPSinks 1 frame/packet stream is using
> almost twice the amount of bandwidth a hinted 3gp file with the same
> audio bitrate is using. And the packets/sec is more than 10 times as
> high.