[Live-devel] Sending periodic metadata XML fragments-- should I use SimpleRTPSource or modify MediaSession?

[Ross Finlayson]

On Aug 11, 2011, at 8:08 AM, Dave McMordie <mcmordie at gmail.com> wrote:
> Great library-- it was a pleasure to integrate!  We are transmitting a sequence of uncorrelated image frames using a subclass of JPEGVideoSource.
> 
> We would also like to transmit a stream of XML fragments (one-to-one with the video frames) which contain information about each frame.
> 
Do "we" not have our own domain name? :-)

Rather than using a separate RTP stream for this per-frame XML data (which would require a separate RTP payload format, and a lot of extra code for both the server and receiver(s), is it possible to store this per-frame data somewhere within the JPEG frame itself?  I.e., does the JPEG format allow for application-specific 'meta data' somewhere within the JPEG frame?  If so, then this would be (by far) the best solution.

(Of course, you really shouldn't be streaming JPEG at all; it's a terrible codec for video streaming.)


>  What I have understood so far from previous threads is that I can create a custom payload format using subclasses of MultiFramedSource / MultiFramedSync.  I would then modify the MediaSession::initiate method to add explicit support for this payload format.  On the server side, I also create a new MediaSubsession containing the source/sink and add it to my MediaSession.

"MediaSession" and "MediaSubsession" are used only by receivers.  Servers (transmitters) use "ServerMediaSession" and (subclasses of) "ServerMediaSubsession".

But you're correct.  Unfortunately, to support a new RTP payload format in receivers, you need to modify the "MediaSession::initiate()" code.  (Someday I hope to fix this, because it's better if developers don't have to modify the supplied code.)

Anyway, there isn't really a suitable RTP payload format for your application (except, perhaps, the payload type "text/t140", defined by RFC 4103 "RTP Payload for Text Conversation").  So you'd need to define your own.

But, as I noted above, the best solution would be to (somehow) store your per-frame XML data within each JPEG frame.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110811/0fbaa34e/attachment.html>