The solution here is simply for someone to implement the RTP Payload
Format for JPEG 2000, as described in
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-avt-rtp-jpeg2000-18.txt
I.e., this would involve defining and implementing two new classes -
"JPEG2000VideoRTPSource" and "JPEG2000VideoRTPSink". These would be
similar to the (but different from and not just subclasses of) the
existing "JPEGVideoRTPSource" and "JPEGVideoRTPSink" classes.
You cannot send or receive JPEG 2000 frames in RTP using our existing
code; you must write new code to implement this new RTP payload
format.
>2) Adding an extra parameter to the SDP file similar to the "RTP
>Payload Format for JPEG 2000 Video Streams":
>
>m=video 49170/2 RTP/AVP 98
>a=rtpmap:98 jpeg2000/90000
>a=fmtp:98 rate=90000;sampling=YCbCr-4:2:0;width=128;height=128
>a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128
>
>3) Parsing this sdp to get the width and height, etc out.
>
>I'm still very new to RTP, etc and I'm not sure how to judge it, is
>this a "bad" hack?
Note (from the Internet-Draft) that these "width" and "height"
parameters, passed in the SDP description, are *optional* parameters
(i.e., servers cannot be expected to include them), and, more
importantly, that they represent the *maximum possible* width and
height of the JPEG 2000 frames. Therefore, you cannot rely upon
these parameters to denote the *actual* width/height of the stream's
frames.
The ony reliable way to get the width and height of each JPEG 2000
frame is to actually parse the JPEG 2000 frame data, which is what
you will need to do anyway in order to decode/display the frame.
I'm a bit puzzled here. Over the last few days, we've seen several
messages posted by people who want to get codec-specific information
from received RTP data, but don't want to actually decode that data.
I don't understand. What is the point of receiving audio or video
data if you don't want to decode it? (Unless, of course, you just
want to write the received data into a file - as "openRTSP" does - in
which case you don't need to care about the codec-specific internal
parameters.)
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
