[Live-devel] H264 multicast streaming question

[Stas Desyatnlkov]

Here is a situation:
The streamer is a black box that's connected to audio and video source. The streamer sends TS with AVC and AAC because the client can only accept TS. The client knows the exact format of the video and audio streams inside TS and wants to connect to the live transmission at any time.
The client knows nothing about session establishment protocols (e.g. RTSP).


From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremy Noring
Sent: Thursday, September 24, 2009 8:17 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 multicast streaming question

On Thu, Sep 24, 2009 at 12:46 AM, Stas Desyatnlkov <stas at tech-mer.com<mailto:stas at tech-mer.com>> wrote:
Hi,
Its obvious that loss of the SPS or PPS results in a lot of grief in the h264 land. The question is what choice do we have in case of no other means of communication besides RTP?
What if the h264 stream is packed inside TS and receiver is not aware of anything else?
I guess in case of LAN streaming where packet loss is rare sending SPS/PPS inband is not that bad of an option would you agree?


It depends.  If you're doing multicast, then sending it in-stream is a bad idea; clients may miss the first sending, which means you'd have to do something weird like insert it when a client connects, or periodically insert it.  If you're doing unicast, it would probably work to send it once in-stream.  In my experience, some clients expect correct sprop-parameter-set and profile-level-id fields (e.g. quicktime), so not populating them is possibly a deal-breaker.

In any event, if you're on a LAN, why would you _ever_ consider not using the associated RTSP session to communicate this information?  And what sort of scenario do you have where there is "no other means of communication besides RTP?"  Quite frankly, I can't possibly think of a situation where either of these statements would be true.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20090929/7384af31/attachment.html>