Re: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-03.txt

[Jonathan Lennox <[e-mail]>]

(Reviewing as an individual).

I had a chance to read over this document.

The packet wire format seems reasonable - I don’t have a lot of experience with JPEG, but I don’t see anything that jumps out at me as problematic.  However, I think the SDP and media type description sections need some refinement.

The semantics of the optional media type parameters are unclear to me.  If the values are essential to decode and/or interpret the stream, why are they optional?  If not, default values are specified in some cases; but for the others, what is a receiver supposed to do if they aren’t present?

Are these values also specified in-band in the bitstream?  If so, are the SDP parameters simply guidance as to what the stream will contain? Are there any circumstances in which the values in the bitstream can vary from the value in the SDP?

In particular, the SDP offer/answer semantics seem to be lacking.  It lists a parameter which isn’t otherwise specified in the document.  In general, for offer/answer, the semantics of all the parameters will need to be spelled out — are these receiver parameters, i.e. a sender must only send a stream which matches the values specified?  Or are they sender parameters?  Can they be negotiated, and if so, how?

On a simpler note, the "transmission-mode” media-type parameter should be specified in the fmtp parameter, rather than as a slash after the SDP; that field is only used for number of channels for audio.  And the example fmtp shouldn’t include spaces after the semicolons.

I think these should all be pretty easy questions to resolve, so hopefully this document can be finished up pretty soon!

Jonathan Lennox
 


> On April 8, 2020 at 5:27 PM, Antonin Descampe <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Dear all,
> 
> As the notification you received indicates, a new version of the RTP payload format for ISO/IEC 21122 (JPEG XS) has been submitted.
> 
> Compared to version 2, a number of changes have been brought to the document, which I summarise hereunder:
> 
> - 2 different possible packetization modes: one based on JPEG XS slices and one based on JPEG XS codestream. The later has been introduced because we needed a packetization mode implying very little processing in a « trans-capsulation » use case.  For instance, when switching from MPEG-2 TS to ST2110-22, we needed a way to packetise that would *not* involve any parsing of the codestream, so as to minimise the processing required by such system translating from one encapsulation to the other. This codestream-based packetization also automatically ensure to fulfil the ST2110-22 requirements of having the same amount of bytes and the same amount of RTP packets per frame. We did leave the slice-based packetization as well as it can be useful in certain use cases and if RTP packets are sent out-of-order by the transmitter (which can be relevant for some implementations of a full SW workflow). Note however that in the slice-based packetization, additional constraint need to be set at rate allocation stage to fulfil ST2110-22 requirements mentioned above.
> - A bit indicating if the transmitter has sent the packets in sequential order. If packets have been sent out-of-order, the slice-based packetization is required to be used.
> - Explicit support for interlace video
> - Re-inclusion of EOC marker to keep the JPEG XS codestream consistent and self-contained.
> 
> Thanks to these changes, the transport of JPEG XS over RTP inherently gives the following guarantees:
> 1. Constant number of bytes and number of packets per frame (ST2110-22).
> 2. No transcoding or deep codestream inspection when changing the encapsulation (see codestream-packetization explanation above).
> 3. Low-latency behaviour.
> 4. No quality loss induced by the transport
> 5. Low complex HW and fast SW decoding. 
> 
> Please provide your comments or questions, if any.
> 
> Kind regards,
> 
> Antonin 
> 
>> Le 8 avr. 2020 à 23:24, [e-mail] <mailto:[e-mail]> a écrit :
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF.
>> 
>>        Title           : RTP Payload Format for ISO/IEC 21122 (JPEG XS)
>>        Authors         : Sébastien Lugan
>>                          Antonin Descampe
>>                          Corentin Damman
>>                          Thomas Richter
>>                          Alexandre Willeme
>> Filename        : draft-ietf-payload-rtp-jpegxs-03.txt
>> Pages           : 23
>> Date            : 2020-04-08
>> 
>> Abstract:
>>   This document specifies a Real-Time Transport Protocol (RTP) payload
>>   format to be used for transporting JPEG XS (ISO/IEC 21122) encoded
>>   video.  JPEG XS is a low-latency, lightweight image coding system.
>>   Compared to an uncompressed video use case, it allows higher
>>   resolutions and frame rates, while offering visually lossless
>>   quality, reduced power consumption, and end-to-end latency confined
>>   to a fraction of a frame.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ <https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/>
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-payload-rtp-jpegxs-03 <https://tools.ietf.org/html/draft-ietf-payload-rtp-jpegxs-03>
>> https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-03 <https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-03>
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-03>
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> 
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>
> 
> --
> Antonin Descampe - Ph.D.
> Compression technologist 
> 
> IntoPIX s.a.
> [phone] (Office)
> [e-mail] <mailto:[e-mail]>
> 
> CONFIDENTIALITY NOTICE: Unless otherwise explicitly or implictly stated, this email message and any of its attachments are the property of intoPIX SA and are strictly confidential.
> If you are an unintended recipient, please notify the sender immediately.
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> -- 
> Jonathan Lennox
> [e-mail]