Re: [payload] EOC marker in RTP transport of JPEG XS

Antonin Descampe <a.descampe@intopix.com> Mon, 03 June 2019 15:57 UTC

From: Antonin Descampe <a.descampe@intopix.com>
To: "kawamoto.j-he@nhk.or.jp" <kawamoto.j-he@nhk.or.jp>
CC: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] EOC marker in RTP transport of JPEG XS
Thread-Index: AQHVFfv1J99E1UTM0UyLttulwXWdNKaJDKiAgADv+YA=
Date: Mon, 03 Jun 2019 15:57:37 +0000
Message-ID: <210FDD85-19E5-4387-9427-EF082A34585D@intopix.com>
References: <4AD3844B-D37B-4D9B-A08B-5C1AC567C40B@intopix.com> <TY2PR01MB37241B21966449E1FC7C407DF1140@TY2PR01MB3724.jpnprd01.prod.outlook.com>
In-Reply-To: <TY2PR01MB37241B21966449E1FC7C407DF1140@TY2PR01MB3724.jpnprd01.prod.outlook.com>
Accept-Language: fr-FR, fr-BE, en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_210FDD8519E543879427EF082A34585Dintopixcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/_3pLcEBJiPnPiyHCyVzQTWMI2EY>
Subject: Re: [payload] EOC marker in RTP transport of JPEG XS
Precedence: list

Dear Kawamoto-san,

Many thanks for your input. Unless there are other comments, we’ll go for the second solution then (simply discard the EOC marker) and update the draft accordingly.

Kind regards,

Antonin

Le 3 juin 2019 à 03:38, kawamoto.j-he@nhk.or.jp<mailto:kawamoto.j-he@nhk.or.jp> a écrit :

Dear Descampe-san,

The socond solution is simple because the metadata packets and the coded-data packets can be clearly classified using slice counters.

In case of the first solution, since the EOC marker is mapped to the same packet as a coded-data, the above clear classification can not be performed.

Best regards,

Junichiro Kawamoto,
NHK (Japan Broadcasting Corporation)

差出人: Antonin Descampe
送信日時: 5月29日水曜日 17:53
件名: [payload] EOC marker in RTP transport of JPEG XS
宛先: payload@ietf.org<mailto:payload@ietf.org>

Dear all,

In the current version of the ID of RTP payload format for ISO/IEC 21122 (JPEG XS)

https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/

the EOC marker (end of codestream, 2 bytes long) is transported in its own RTP packet, which leads to a suboptimal situation when padding is enabled, as a complete RTP packet is used for transporting only 2 bytes of metadata.

Two solutions are envisioned to solve this issue:
1/ Include the EOC marker in the previous packet (the one containing entropy coded data from the last slice).
2/ Simply drop the EOC marker and mark the packet containing data from the last slice as the last packet of the frame.

We advocate for the second solution as it avoids mixing entropy-coded data and metadata within the same RTP packet, but it also has the drawback to require to regenerate an EOC marker at decoding side if a fully compliant JPEG XS codestream is needed.

Any opinion/advice on this ?

Any other comment on the current version of the RTP payload format is also welcome. FYI, the current version is a much simpler version than the previous one and is now in a pretty mature stage.

Kind regards,

Antonin Descampe

--
Antonin Descampe - Ph.D.
Compression technologist

IntoPIX s.a.
+32 10 23 84 70 (Office)
a.descampe@intopix.com<mailto:a.descampe@intopix.com>

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.

[payload] EOC marker in RTP transport of JPEG XS Antonin Descampe
Re: [payload] EOC marker in RTP transport of JPEG… kawamoto.j-he@nhk.or.jp
Re: [payload] EOC marker in RTP transport of JPEG… Antonin Descampe