[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] JP2RTP & JPWL & JPSEC

Andrew,

[inline]

On 6 Jun 2005, at 10:08, Andrew Leung wrote:
There is some discussion within the ISO JPEG groups to propose a new RTP
format for a new project going on there called: JPWL (JPEG 2000 for
WireLess). One idea for them was to adopt the current IETF work, JP2RTP
(our work), with an amendment to handle JPWL capabilities. Similar work
is going on in JPSEC (JPEG 2000 for Security & Authentication)

We would like to ask AVT chairs & members their opinion on extending
support in JP2RTP for these 2 related applications. As this work item,
JP2RTP, has been extended quite long, we would like to have it goto RFC
soon but if we can avoid confusion in the longer term, or avoid
amendments to it by others, we would be interested in merging this work
together and completing it here.

I have researched JPWL and found that it is probably 100% compatible
with JP2RTP. Almost all of JPWL extended functionality is through extra
markers in the codestream. These codestream extensions are designed not
to disturb a JPEG 2000 decoder from processing it properly. (i.e. a
decoder is designed to ignore unknown options and the markers are
specified in their own specification outside the normal range of JPEG
2000 and other JPEG markers.) JP2RTP is specified to send JPEG 2000
codestream in a packetized manner, regardless of markers.

Including JPWL support in JP2RTP may be as simple as adding the proper
SDP/MIME option at the start of the session to let receivers know to do
extra processing for JPWL markers. The JPWL markers and proper handling
will be described in detail in the ISO standard (it will be standardized
at the end of the year or so.)

I know very little about JPWL, but if it's possible to effectively use the existing RTP payload format, that would seem a more effective solution than defining another payload format.

That said, what is the purpose of the JPWL extensions? While the bit stream may be compatible with the existing RTP payload format, is there other functionality that might be affected by RTP packetisation? For example, some previous payload formats spend considerable effort to get tolerance to bit errors for wireless environments, and if that feature is needed there may be an argument for changing the RTP payload format to support it.

Another highly related project following a similar pattern is JPSEC
(JPEG 2000 for Security & Authentication) which has a similar design
principle as JPWL. Changes to the codestream should not break decoder
processing, even if the image is encrypted. JPSEC codestreams encrypt
the image in a way that the decoder can properly decode the image but
fails to display properly at varying levels.

JPSEC processing is outside of the transmission but transmission level
information would be required for receiver processing. In-band signaling
(i.e. this frame/packet is encrypted) and SDP/MIME signaling (i.e.
frames in this session will be encrypted) would be all that is needed
for JP2RTP to support this application.

If it's possible to fit this into the current payload format in a compatible manner, that's clearly desirable. There would clearly need to be discussion in the payload format to describe then JPSEC is suitable versus SRTP, but that doesn't seem to be unreasonable. The more difficult issue here may be SDP signalling, especially if there's a need to convey keying material (i.e. do the SDP sdescriptions or kmgmt extensions work for this application, or is there a need for some new signalling).

Colin


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt