Authors,
While reviewing this document during AUTH48, please resolve (as necessary)
the following questions, which are also in the source file.
1) <!-- [rfced] Does "but between transformed values" mean "but with
prediction between transformed values"? Please clarify.
Original:
* Intra frame coding without prediction between pixel values but
between transformed values for low delay encoding;
-->
2) <!-- [rfced] For clarity, may this text be updated as follows?
Original:
* Multiple decoding and re-encoding without severe visual quality
degradation; and
Perhaps:
* the ability to decode and re-encode multiple times without severe
visual quality degradation; and
-->
3) <!-- [rfced] We do not believe we see "I" used in this manner, though we
do see instances of "i". Please review and let us know if "I" should be
removed or if other changes are needed.
Original Section 2.2:
* I: intra
Original Section 3.2.1:
* sum (i=x, y, f(i)) : a summation of f(i) with i taking all integer
values from x up to and including y
Original Section 5.3.7:
The array index i specifies an indicator for the color
component; ...
-->
4) <!-- [rfced] For clarity, may we update the text as follows? If this is
incorrect, please clarify what is following widely used industry practices.
Or is the exception per widely used industry practices?
Original:
The operators and the order of precedence are the same as used in the
C programming language [ISO9899], with the exception of the operators
described in the Section 3.2.1 and Section 3.2.2 following widely
used industry practices for video codecs.
Perhaps:
Following widely used industry practices for video codecs, the operators
and the order of precedence are the same as used in the C programming
language [ISO9899], with the exception of the operators described in the
Sections 3.2.1 and 3.2.2.
-->
5) <!-- [rfced] Should "square parentheses" be "square brackets"?
Original:
Square parentheses are used for the indexing
of arrays.
-->
6) <!-- [rfced] We are having trouble parsing "depending on the Chroma
format sampling structure" - what is depending on that structure?
Original:
The variables SubWidthC, SubHeightC and NumComps are specified in
Table 2, depending on the chroma format sampling structure, which is
specified through chroma_format_idc.
Perhaps:
The variables SubWidthC, SubHeightC, and NumComps are specified in
Table 2, according to the chroma format sampling structure, which is
specified through chroma_format_idc.
-->
7) <!-- [rfced] Is "1D" needed here, as section 4.4.1 indicates that the
zig-zag process converts a 2D array into a 1D array? Simplifying the
sentence improves readability.
Original:
* The variable forwardScan is derived by invoking zig-zag scan order
1D array initialization process as specified in Section 4.4.1 with
input parameters blkWidth and blkHeight.
Perhaps:
* The variable forwardScan is derived by invoking the zig-zag scan
order process as specified in Section 4.4.1 with
input parameters blkWidth and blkHeight.
-->
8) <!-- [rfced] For readability, may we update this sentence as follows?
Original:
The APV bitstream is described in this document using syntax code
based on the C programming language [ISO9899] and uses its if/else,
while, and for keywords as well as functions defined within this
document.
Perhaps:
The APV bitstream is described using syntax code
based on the C programming language [ISO9899] - including use of the
keywords if/else, while, and for - as well as functions defined within
this document.
-->
9) <!-- [rfced] Can "of this version of the document" be dropped in
multiple places, since section references are assumed to be in this
document (unless specified otherwise) and because the HTML and PDF link to
the relevant sections of the given document? For example:
Original Section 5.3.3:
* reserved_zero_8bits
MUST be equal to 0 in bitstreams conforming to the profiles
specified in Section 9 of this version of document. Values of
reserved_zero_8bits greater than 0 are reserved for future use.
Decoders conforming to the profiles specified in Section 9 of this
version of document MUST ignore PBU with values of
reserved_zero_8bits greater than 0.
Original Section 5.3.5:
* reserved_zero_8bits
MUST be equal to 0 in bitstreams conforming to the profiles
specified in Section 9 of this version of document. Values of
reserved_zero_8bits greater than 0 are reserved for future use.
Decoders conforming to the profiles specified in Section 9 of this
version of document MUST ignore PBU with values of
reserved_zero_8bits greater than 0.
-->
10) <!-- [rfced] We are trying to draw a more clear connection between the
text before and after the semicolon. Please consider whether the suggested
text conveys the intended meaning. Otherwise, please clarify.
Note that this text appears multiple times; we will update all similar
instances based on the outcome of this discussion.
Original:
The array index i specifies an indicator for the color
component; when chroma_format_idc is equal to 2 or 3, 0 for Y, 1
for Cb and 2 for Cr.
Perhaps:
The array index i specifies an indicator for the color
component when chroma_format_idc is equal to 2 or 3, Y is 0,
Cb is 1, and CR is 2.
-->
11) <!-- [rfced] Please confirm that no additional explanatory text is
needed after Figure 21.
-->
12) <!-- [rfced] How may we expand "DC"? Differential coding? Will it be
understood by readers without expansion?
Original:
* abs_dc_coeff_diff
specifies the absolute value of the difference between the current
DC transform coefficient level and PrevDC.
-->
13) <!-- [rfced] "It is the requirement of bitstream conformance" is a bit
awkward to read. Please consider whether the suggested update is correct.
Otherwise, please clarify.
Original:
It is the requirement of bitstream conformance that
the coded tiles of the frame MUST contain tile data for every MB
of the frame, such that the division of the frame into tiles and
the division of the tiles into MBs each forms a partitioning of
the frame.
Perhaps:
For conforming bitstreams, the coded tiles of the frame MUST contain
tile data for every MB
of the frame, such that the division of the frame into tiles and
the division of the tiles into MBs each forms a partitioning of
the frame.
-->
14) <!-- [rfced] Please clarify "(when chroma_format_idc is equal to 2 or
3, Y, Cb, and Cr)." Perhaps "(when chroma_format_idc is equal to 2 or 3,
and Y, Cb, and Cr are specified)"?
Original:
Outputs of this process are the
reconstructed samples of all the NumComps color components (when
chroma_format_idc is equal to 2 or 3, Y, Cb, and Cr) for the current
MB.
Similarly, please let us know how/if mention of Cb and Cr may be clarified
here as well?
Original:
* When chroma_format_idc is not equal to 0, let recSamples[1] be a
(MbWidthC)x(MbHeightC) array of the reconstructed samples of the
second color component (when chroma_format_idc is equal to 2 or 3,
Cb).
...
* When chroma_format_idc is not equal to 0, let recSamples[2] be a
(MbWidthC)x(MbHeightC) array of the reconstructed samples of the
third color component(when chroma_format_idc is equal to 2 or 3,
Cr).
-->
15) <!-- [rfced] Section 6.2: Is there text missing after these bullets?
Nothing appears after "the following applies." Also, the formatting here
looks odd. Please review and let us know how the text may be updated.
* For yIdx = 0..numBlkY - 1, the following applies:
o For xIdx = 0..numBlkX - 1, the following applies:
-->
16) <!-- [rfced] Should the last 3 bulleted items be regular text (i.e.,
not part of the bulleted list)?
6.3.2.2. Transformation process
Inputs to this process are:
* a variable nTbS specifying the sample size of scaled transform
coefficients, and
* a list of scaled transform coefficients x with elements x[j], with
j = 0..(nTbS - 1).
* Output of this process is the list of transformed samples y with
elements y[i], with i = 0..(nTbS - 1).
* The transformation matrix derivation process as specified in
Section 6.3.2.3. invoked with the transform size nTbS as input,
and the transformation matrix transMatrix as output.
* The list of transformed samples y[i] with i = 0..(nTbS - 1) is
derived as follows:
y[i] = sum(j = 0, nTbS - 1, transMatrix[i][j] * x[j])
-->
17) <!-- [rfced] Please confirm that no additional explanatory text is
needed after Figure 28. -->
18) <!-- [rfced] Will readers be familiar with CIE 1931? Please consider
whether a reference should be added. Note that "CIE 1931" is mentioned 4
times. If you would like to add a reference, please provide the reference
entry.
Original:
* primary_chromaticity_x[i]
specifies a 0.16 fixed-point format of X chromaticity coordinate
of mastering display as defined by CIE 1931, where i = 0, 1, 2
specifies Red, Green, Blue respectively.
-->
19) <!-- [rfced] Please note that we expanded UUID as "Universally Unique
Identifier." Please let us know if any corrections are needed.
Original:
* uuid
MUST be a 128-bit value specified as a generated UUID according to
the procedures specified in [RFC9562].
-->
20) <!-- [rfced] We are having trouble parsing this sentence. Perhaps "to
specifically create different sets of constraints" is intended?
Original:
For example, a certain level L and a certain band
B can be combined with either profile X or profile Y to specifically
different set of constraints.
-->
21) <!-- [rfced] This sentence appears many times in this document. May we
update it as follows?
Original:
Any levels and bands constraints specified in Section 9.4 MUST be
fulfilled.
Perhaps:
Any levels and bands MUST adhere to the constraints specified in
Section 9.4.
-->
22) <!-- [rfced] Is "level B" correct, as opposed to "band B"? Note that
"level B" appears multiple times.
* The coded frame is indicated to conform to a band (by a specific
value of band_idc) that is lower than or equal to level B.
-->
23) <!-- [rfced] We have updated the format of the header row of table 4 so
it fits within the line-length limitiation. Please review carefully and
let us know if and adjustments are needed or if you have other suggestions
for how it can be rendered.
-->
24) <!-- [rfced] "no read" can be difficult to parse. Perhaps this can be
reworded?
Original:
The implementation MUST ensure that no read outside
allocated and initialized memory occurs.
Perhaps A:
The implementation MUST ensure that any data outside
of the allocated and initialized memory cannot be read.
Perhaps B:
The implementation MUST ensure that there is no
data outside of the allocated and initialized memory.
-->
25) <!-- [rfced] [ISO9899] Please review.
This reference currently points to a withdrawn version of ISO/IEC 9899:
https://www.iso.org/standard/74528.html.
The most current version of this reference is ISO/IEC 9899:2024.
Should this reference be updated to point to the most current version?
Current:
[ISO9899] ISO/IEC, "Information technology - Programming languages -
C", ISO/IEC 9899:2018, 2018,
<https://www.iso.org/standard/74528.html>.
-->
26) <!-- [rfced] [CEA-861.3] Please review.
CEA-861.3 appears to have been placed in "Historical" status (see:
https://webstore.ansi.org/standards/cea/cea8612015-1528168). The most
current version of this standard appears to be CTA-861.3-A (see:
https://www.cta.tech/standards/cta-8613-a/). Note that the Consumer
Electronics Association (CEA) changed its name to the "Consumer
Technology Association" (CTA) in 2015.
Should this reference be updated to point to CTA-861.3-A?
Current:
[CEA-861.3]
CEA, "CEA-861.3, HDR Static Metadata Extension", January
2015.
-->
27) <!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
28) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
Sandy Ginoza
RFC Production Center
On Feb 2, 2026, at 10:22 PM, [email protected] wrote:
*****IMPORTANT*****
Updated 2026/02/02
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9924.xml
https://www.rfc-editor.org/authors/rfc9924.html
https://www.rfc-editor.org/authors/rfc9924.pdf
https://www.rfc-editor.org/authors/rfc9924.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9924-diff.html
https://www.rfc-editor.org/authors/rfc9924-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9924-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9924
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 9924 (draft-lim-apv-09)
Title : Advanced Professional Video
Author(s) : Y. Lim, M. Park, M. Budagavi, R. Joshi, K. Choi
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
