AcademySoftwareFoundation
diff --git a/‎CONTRIBUTING.md‎
Lines changed: 2 additions & 2 deletions b/‎CONTRIBUTING.md‎
Lines changed: 2 additions & 2 deletions
diff --git a/‎ColorPreservation.md‎
Lines changed: 5 additions & 5 deletions b/‎ColorPreservation.md‎
Lines changed: 5 additions & 5 deletions
diff --git a/‎EditorialWorkflow.md‎
Lines changed: 2 additions & 2 deletions b/‎EditorialWorkflow.md‎
Lines changed: 2 additions & 2 deletions
diff --git a/‎EncodeAv1.md‎
Lines changed: 3 additions & 3 deletions b/‎EncodeAv1.md‎
Lines changed: 3 additions & 3 deletions
diff --git a/‎EncodeDNXHD.md‎
Lines changed: 6 additions & 7 deletions b/‎EncodeDNXHD.md‎
Lines changed: 6 additions & 7 deletions
diff --git a/‎EncodeHTJ2K.md‎
Lines changed: 6 additions & 6 deletions b/‎EncodeHTJ2K.md‎
Lines changed: 6 additions & 6 deletions
diff --git a/‎EncodeHevc.md‎
Lines changed: 16 additions & 7 deletions b/‎EncodeHevc.md‎
Lines changed: 16 additions & 7 deletions
diff --git a/‎EncodeMJPEG.md‎
Lines changed: 1 addition & 1 deletion b/‎EncodeMJPEG.md‎
Lines changed: 1 addition & 1 deletion
@@ -16,7 +16,7 @@ We are attempting to do all the documentation using markdown, in particular usin
 
 ## Coding Style
 
-The test suite has been developed using python-3, and has been designed to work on windows, osx and linux.
+The test suite has been developed using python-3, and has been designed to work on Windows, MacOS and Linux.
 
 ## How to Contribute a Bug Fix or Change or additional Documentation
 
@@ -26,4 +26,4 @@ ORI Encoding Guidelines is licensed under the [Apache License 2.0](LICENSE.md) l
 
 Project committers will review the contribution in a timely manner, and advise of any changes needed to merge the request.
 
-[governance policies]: GOVERNANCE.md
+[governance policies]: GOVERNANCE.md
@@ -1,16 +1,16 @@
 ---
 layout: default
-title: RGB to YCrCb Conversion
+title: RGB to YCbCr Conversion
 nav_order: 3
 parent: Encoding Overview
 
 ---
 
 
 
-# RGB to YCrCb Conversion <a name="yuv"></a>
+# RGB to YCbCr Conversion <a name="yuv"></a>
 
-We would like ffmpeg to do as little as possible in terms of color space conversion. i.e. what comes in, goes out. The problem is that most of the codecs prefer to convert from RGB to YUV conversion (technically YCrCb). Do be aware that a number of codecs do support native RGB encoding (including h264, hevc, vp9, av1), but they are not typically supported in web browsers.
+We would like ffmpeg to do as little as possible in terms of color space conversion. i.e. what comes in, goes out. The problem is that most of the codecs prefer to convert from RGB to YUV conversion (technically YCbCr). Do be aware that a number of codecs do support native RGB encoding (including h264, hevc, vp9, av1), but they are not typically supported in web browsers.
 
 The main problem is that ffmpeg by default assumes that any unknown still image format has a color space of [rec601](https://en.wikipedia.org/wiki/Rec._601) which is very unlikely to be the color space your source media was generate in. So unless you tell it otherwise it will attempt to convert from that colorspace producing a color shift.
 
@@ -98,7 +98,7 @@ ffmpeg -y -i ../sourceimages/chip-chart-1080-noicc.png \
 -vf "zscale=m=709:min=709:rangein=full:range=limited"
 ```
 
-[zscale](https://github.com/sekrit-twc/zimg) is an alternative to libswscale, which does produce pretty good results for image resizing, but purely for RGB to YCrCb conversion libswscale appears very slightly better. It is required to be explicitly compiled into ffmpeg.
+[zscale](https://github.com/sekrit-twc/zimg) is an alternative to libswscale, which does produce pretty good results for image resizing, but purely for RGB to YCbCr conversion libswscale appears very slightly better. It is required to be explicitly compiled into ffmpeg.
 
 More detailed docs are: [here](http://underpop.online.fr/f/ffmpeg/help/zscale.htm.gz)
 
@@ -157,4 +157,4 @@ ffmpeg -y -i ../sourceimages/chip-chart-1080-noicc.png \
    ./chip-chart-yuvconvert/spline444out_color_matrix.mp4
 ```
 
-Note, there are a lot of other flags often used with the swscale filter (such as -sws_flags spline+full_chroma_int+accurate_rnd ) which really have minimal impact in the RGB to YCrCb conversion, if you are not resizing the image. For more details on this see [SWS Flags](EncodeSwsScale.html) section.
+Note, there are a lot of other flags often used with the swscale filter (such as -sws_flags spline+full_chroma_int+accurate_rnd ) which really have minimal impact in the RGB to YCbCr conversion, if you are not resizing the image. For more details on this see [SWS Flags](EncodeSwsScale.html) section.
@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Adding Timecode and Editorial Workflow
-nav_order: 5
+nav_order: 5.1
 parent: Encoding Overview
 ---
 
@@ -169,7 +169,7 @@ Part of the decision is whether you want a single file to also contain the audio
 If an AVID imports a media file with no timecode, it will default to 01:00:00:00.
 For this reason it can be desirable to do one of the above approaches, but do work with editorial to confirm what they would like.
 
-[OpAtom](EncodeDNXHD.html#op-atom-mxf) files do not get directly imported into the AVID, instead you copy them directly into the /Users/Shared/AvidMediaComposer/Avid MediaFiles/MXF/{NUMBER} folder (e.g. /Users/Shared/AvidMediaComposer/Avid MediaFiles/MXF/2) on OSX or C:\Avid MediaFiles\MXF\{NUMBER} on windows. You can make a higher number, but Media Composer will also scan existing folders. Media composer will scan for new files and create (or update) a msmMMOB.mdb file, which is a database of the MOB ID's of the files. This can then be dragged into a Avid Bin to import the new files.
+[OpAtom](EncodeDNXHD.html#op-atom-mxf) files do not get directly imported into the AVID, instead you copy them directly into the /Users/Shared/AvidMediaComposer/Avid MediaFiles/MXF/{NUMBER} folder (e.g. /Users/Shared/AvidMediaComposer/Avid MediaFiles/MXF/2) on MacOS or C:\Avid MediaFiles\MXF\{NUMBER} on windows. You can make a higher number, but Media Composer will also scan existing folders. Media composer will scan for new files and create (or update) a msmMMOB.mdb file, which is a database of the MOB ID's of the files. This can then be dragged into a Avid Bin to import the new files.
 
 NOTE, there is also an associated folder called UME - /Users/Shared/AvidMediaComposer/Avid MediaFiles/UME/{NUMBER} that can take [Op1a](EncodeDNXHD.html#op1a-mxf) files. However, with recent testing (version 2023.8.2.58057.0), the metadata does not reliably get imported.
 
 
@@ -63,7 +63,7 @@ ffmpeg -r 24 -start_number 1 -i inputfile.%04d.png -frames:v 200 -c:v libsvtav1
 ```
 
 | --- | --- |
-| **-crf 18** | This is the constant rate factor, controlling the default quality in the range 0-63. By default this is set to 50, which is a little on the low side, using values closer to 18 is recommended, but this does come at the expense of file-size. For more on this see the [CRF comparison](#crf-comparison-for-libsvtav1) below. |
+| **-crf 18** | This is the constant rate factor, controlling the default quality in the range 0-63. By default this is set to 50, which is a little on the low quality side, using values closer to 18 is recommended, but this does come at the expense of file-size. For more on this see the [CRF comparison](#crf-comparison-for-libsvtav1) below. |
 | **-preset 5** | Help with a trade-off between encoding speed and compression efficiency. Supported preset range in the 0-13. See below for comparisons |
 
 See also:
@@ -124,7 +124,7 @@ Libaom has an aggressive denoiser, which can be pretty good for animated media,
 
 ### cpu-speed Comparison for libaom-av1
 
-To help pick appropriate values with the cpu-speed flag, we have run the [Test Framework](enctests/README.html) through one of the test media. You can see that values are
+To help pick appropriate values with the cpu-speed flag, we have run the [Test Framework](enctests/README.html) through one of the test media. You can see those values below.
 
 | ![](enctests/reference-results/aomav1-crf-test-encode_time.png)  | ![](enctests/reference-results/aomav1-crf-test-encode_time_zoom.png) |
 | This is showing cpu-speed values against encoding time. You can see that values of 1 and 2 are more than 15 minutes, where most other encoders are closer to the 30 second range. | Same graph of cpu-speed value against encoding time a 0-500 scale. This is showing cpu-used 5 is now just twice as slow, as Libsvtav1, but at 422 vs. 420 |
@@ -146,4 +146,4 @@ See Also - note these are all guides for AOMENC (the AOM encoder that is part of
 Supported pixel formats:
 yuv420p yuvj420p yuv420p10le yuv420p12le yuv422p yuvj422p yuv422p10le yuv422p12le yuv444p yuvj444p yuv444p10le yuv444p12le
 
-There is no CRF flag, so you use the -gp flag, the recommended starting point is about 100. However, we have been unable to get an substantial speed improvement over AOM.
+There is no CRF flag, so you use the -qp flag, the recommended starting point is about 100. However, we have been unable to get an substantial speed improvement over AOM.
@@ -1,6 +1,6 @@
 ---
 layout: default
-nav_order: 4.6
+nav_order: 4.4
 title: DNxHD Encoding
 parent: Codec Comparisons
 ---
@@ -76,7 +76,7 @@ comparisontest:
        less: 0.00195
 -->
 ```console
-ffmpeg -y -r 24 -i inputfile.%04d.png -vframes 100 \
+ffmpeg -y -r 24 -i inputfile.%04d.png -frames:v 100 \
      -c:v dnxhd -profile:v dnxhr_444 \
      -color_primaries bt709 -color_range tv -color_trc bt709 -colorspace rgb \
      -pix_fmt gbrp10le outputfile.mov
@@ -107,7 +107,7 @@ comparisontest:
        less: 0.00195
 -->
 ```console
-ffmpeg -y -r 24 -start_number 2500 -i inputfile.%04d.png  -vframes 100 \
+ffmpeg -y -r 24 -start_number 2500 -i inputfile.%04d.png  -frames:v 100 \
     -pix_fmt yuv422p \
     -vf "scale=in_range=full:in_color_matrix=bt709:out_range=tv:out_color_matrix=bt709" \
     -c:v dnxhd -profile:v dnxhr_sq \
@@ -137,7 +137,7 @@ comparisontest:
        less: 0.00195
 -->
 ```console
-ffmpeg -y -r 24 -i inputfile.%04d.png -vframes 100 -pix_fmt yuv422p \
+ffmpeg -y -r 24 -i inputfile.%04d.png -frames:v 100 -pix_fmt yuv422p \
     -pix_fmt yuv422p \
     -vf "scale=in_range=full:in_color_matrix=bt709:out_range=tv:out_color_matrix=bt709" 
     -c:v dnxhd -profile:v dnxhr_sq \
@@ -172,10 +172,9 @@ comparisontest:
        less: 0.00195
 -->
 ```console
-ffmpeg -y -r 24 -i inputfile.%04d.png -vframes 100 \
-    -vf "in_range=full:in_color_matrix=bt709:out_range=tv:out_color_matrix=bt709" \
+ffmpeg -y -r 24 -i inputfile.%04d.png -frames:v 100 \
+    -vf "scale=in_range=full:in_color_matrix=bt709:out_range=tv:out_color_matrix=bt709" \
     -pix_fmt yuv422p10 -c:v dnxhd -b:v 175M \
-     -vf "scale=in_color_matrix=bt709:out_color_matrix=bt709" \
      -color_primaries bt709 -color_range tv -color_trc bt709 -colorspace bt709 \
       outputfile.mov
 ```
 
@@ -1,6 +1,6 @@
 ---
 layout: default
-nav_order: 4.5
+nav_order: 4.7
 title: JPEG2000 HTJ2K Encoding
 parent: Codec Comparisons
 ---
@@ -84,8 +84,8 @@ The advantage of using OIIO over ojph_compress are:
 Creating HTJ2K files can be done on the command line with oiiotool, e.g.:
 
 ```console
-oiiotool -t STARTFRAME-ENDFRAME –parallel-frames -i INPUTFRAMESEQ.%05d.tif \
-     –compression htj2k --attrib jph:qstep 0.001 -o OUTPUTFRAMESEQ.%05d.j2c
+oiiotool -t STARTFRAME-ENDFRAME --parallel-frames -i INPUTFRAMESEQ.%05d.tif \
+     --compression htj2k --attrib jph:qstep 0.001 -o OUTPUTFRAMESEQ.%05d.j2c
 ```
 
 Without the jph:qstep flag, lossless mode is used, which is typically quite a bit smaller than many other compression schemes, but not typically small enough for reviews.
@@ -94,7 +94,7 @@ Without the jph:qstep flag, lossless mode is used, which is typically quite a bi
 | *–attrib jph:block_size 64,64* | The older JPEG2000 standard used to default to 32,32 but this does seem to result in a smaller file, this is the default for OIIO. |
 | *–attrib jph:prog_order RPCL* | (see [below](#progression-order)). |
 
-While JPEG2000 can support YCrCb this openimageio implementation assumes that we are only generating RGB results.
+While JPEG2000 can support YCbCr this openimageio implementation assumes that we are only generating RGB results.
 
 ### HTJ2K Wrapping J2C files in container
 
@@ -144,14 +144,14 @@ The progression order (typically a prog_order flag in openjph, or jph:prog_order
 | Flag | Meaning | When to use it |
 | :---- | :---- | :---- |
 | LRCP | Layer -\> Resolution -\> Component -\> Position | Good for progressive quality over full image, particularly useful if you have multiple layers (not currently supported by OIIO). |
-| RLCP | Resolution -\> Layer -\> Component -\> Position | Prioritizes lower resolutions first, allows you to load all of the layers at a lower resolution and then  |
+| RLCP | Resolution -\> Layer -\> Component -\> Position | Prioritizes lower resolutions first, allows you to load all of the layers at a lower resolution and then load in the higher resolutions |
 | RPCL | Resolution -\> Position -\> Component -\> Layer | Optimized for random access and tiling. |
 | PCRL | Position -\> Component -\> Resolution -\> Layer | Less common, spatial prioritisation, good for large images where you are viewing zoomed in sections of it. |
 | CPRL | Component -\> Position -\> Resolution -\> Layer | Used when components are needed separately, e.g. YUV where you might just want Y first, rarely used in VFX. |
 
 Of these settings picking either RPCL or LRCP are the two most common progression orders. OIIO does not currently support layers, so really LRCP and RLCP are very similar.
 
-For many cases position can be ignored, unless you start generating particularly large images where you are only interested in part of that large picture. For example having a 360-video where you are only viewing part of the overall picture. This may be where you would also want to tweak the precincts parameters of the codec. This is definately an area that JPEG2000 comes into its own, since
+For many cases position can be ignored, unless you start generating particularly large images where you are only interested in part of that large picture. For example having a 360-video where you are only viewing part of the overall picture. This may be where you would also want to tweak the precincts parameters of the codec. This is definitely an area where JPEG 2000 shines, as its wavelet-based architecture allows for efficient resolution scalability and partial decoding, which is ideal for massive image datasets.
 
 ## HTJ2K Decoding and Playback
 
 
@@ -1,12 +1,21 @@
 ---
 layout: default
-nav_order: 4.5
+nav_order: 4.2
 title: HEVC/H.265 Encoding
 parent: Codec Comparisons
 ---
 
 # HEVC/H.265 Encoding
 
+<details open markdown="block">
+  <summary>
+    Table of contents
+  </summary>
+  {: .text-delta }
+1. TOC
+{:toc}
+</details>
+
 H.265 (High Efficiency Video Compression - HEVC) is one of the replacements for H.264. It allows for a reduction of file size compared to H.264 of 25-50% and supports frame formats up to 8K (UHDTV). It also has support for HDR, which we go into more [here](enctests/HDR_Encoding.html).
 
 There is Browser support for H265 on Microsoft Edge, Google Chrome and Safari, but not Firefox.
@@ -16,7 +25,7 @@ See [ffmpeg h265 docs](https://trac.ffmpeg.org/wiki/Encode/H.265)
 There are four HEVC encoders available to ffmpeg:
 
 * [libx265](#libx265)
-* [hevc_videotoolbox](#hevc_videotoolbox) - Available on OSX via the videotoolbox library.
+* [hevc_videotoolbox](#hevc_videotoolbox) - Available on MacOS via the videotoolbox library.
 * [hevc_nvenc](#hevc_nvenc) - NVIDIA GPU encoder.
 * hevc_qsv - Intel Quick Sync Video Acceleration.
 
@@ -51,13 +60,13 @@ comparisontest:
 ffmpeg -r 24 -start_number 1 -i inputfile.%04d.png -frames:v 200 -c:v libx265 \
     -pix_fmt yuv420p10le -crf 22 -preset slow -sws_flags spline+accurate_rnd+full_chroma_int \
     -vf "scale=in_range=full:in_color_matrix=bt709:out_range=tv:out_color_matrix=bt709" \
-    -color_range 1 -colorspace 1 -color_primaries 1 -color_trc 2 \
+    -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc iec61966-2-1 \
     -movflags faststart -y outputfile.mp4
 ```
 
 | -- | -- |
 | -preset medium | Can be one of ultrafast, superfast, verfast, faster, fast, medium, slow, slower, and placebo |
-| -crf 22 | Similar to h264, default is 28, but should be similar to crf 22 |
+| -crf 22 | Similar to h264, default is 28 which is on the low quality side |
 | -x265-params lossless=1 | Does lossless encoding, -crf 0 is not required |
 | -tag:v hvc1 | To make it "Apple "Industry standard" compliant |
 | -profile main | Profile can be one of main or main10 or main12 |
@@ -82,9 +91,9 @@ x265_crf(x264_crf) = 1.09 * x264_crf −  4.19
 Below is showing a comparison of different preset values with a crf value of 18.
 Its showing that you really can just encode with -preset medium or -preset slow anything higher is really not gaining you anything.
 
-| ![](enctests/reference-results/hevc-test-encode_time.png)  This is showing CRF values against encoding time. |
-| ![](enctests/reference-results/hevc-test-filesize.png) This is showing CRF values against file size. |
-| ![](enctests/reference-results/hevc-test-vmaf_harmonic_mean.png) This is showing CRF values against VMAF harmonic mean |
+| ![](enctests/reference-results/hevc-test-encode_time.png)  This is showing preset values against encoding time. |
+| ![](enctests/reference-results/hevc-test-filesize.png) This is showing preset values against file size. |
+| ![](enctests/reference-results/hevc-test-vmaf_harmonic_mean.png) This is showing preset values against VMAF harmonic mean |
 
 ## hevc_videotoolbox
 
 
@@ -1,6 +1,6 @@
 ---
 layout: default
-nav_order: 4.5
+nav_order: 4.8
 title: MJPEG Encoding
 parent: Codec Comparisons
 ---