Sync with latest script

38 files changed, 126 insertions, 126 deletions

diff --git a/src/3rdparty/libjpeg/README b/src/3rdparty/libjpeg/README
index d1a57612a..bf58bdd3d 100644
--- a/src/3rdparty/libjpeg/README
+++ b/src/3rdparty/libjpeg/README
@@ -91,7 +91,7 @@ considerable functionality beyond the bare JPEG coding/decoding capability;
 for example, the color quantization modules are not strictly part of JPEG
 decoding, but they are essential for output to colormapped file formats or
 colormapped displays.  These extra functions can be compiled out of the
-library if not retquired for a particular application.  We have also included
+library if not required for a particular application.  We have also included
 "jpegtran", a utility for lossless transcoding between different JPEG
 processes, and "rdjpgcom" and "wrjpgcom", two simple applications for
 inserting and extracting textual comments in JFIF files.
@@ -104,7 +104,7 @@ be reliable, portable, industrial-strength code.  We do not claim to have
 achieved that goal in every aspect of the software, but we strive for it.
 
 We welcome the use of this software as a component of commercial products.
-No royalty is retquired, but we do ask for an acknowledgement in product
+No royalty is required, but we do ask for an acknowledgement in product
 documentation, as described under LEGAL ISSUES.
 
 
@@ -189,7 +189,7 @@ been removed altogether, and the GIF writer has been simplified to produce
 resulting GIF files are larger than usual, but are readable by all standard
 GIF decoders.
 
-We are retquired to state that
+We are required to state that
     "The Graphics Interchange Format(c) is the Copyright property of
     CompuServe Incorporated.  GIF(sm) is a Service Mark property of
     CompuServe Incorporated."
diff --git a/src/3rdparty/libjpeg/change.log b/src/3rdparty/libjpeg/change.log
index 9cc6ce772..74102c0db 100644
--- a/src/3rdparty/libjpeg/change.log
+++ b/src/3rdparty/libjpeg/change.log
@@ -71,7 +71,7 @@ Version 6a  7-Feb-96
 
 Library initialization sequence modified to detect version mismatches
 and struct field packing mismatches between library and calling application.
-This change retquires applications to be recompiled, but does not retquire
+This change requires applications to be recompiled, but does not require
 any application source code change.
 
 All routine declarations changed to the style "GLOBAL(type) name ...",
diff --git a/src/3rdparty/libjpeg/coderules.doc b/src/3rdparty/libjpeg/coderules.doc
index aa87d6ad4..0ab5d9bd3 100644
--- a/src/3rdparty/libjpeg/coderules.doc
+++ b/src/3rdparty/libjpeg/coderules.doc
@@ -39,7 +39,7 @@ source code by using macros to substitute shorter names.)
 We use function prototypes everywhere; we rely on automatic source code
 transformation to feed prototype-less C compilers.  Transformation is done
 by the simple and portable tool 'ansi2knr.c' (courtesy of Ghostscript).
-ansi2knr is not very bright, so it imposes a format retquirement on function
+ansi2knr is not very bright, so it imposes a format requirement on function
 declarations: the function name MUST BEGIN IN COLUMN 1.  Thus all functions
 should be written in the following style:
 
@@ -85,7 +85,7 @@ so that the result is guaranteed to be of type size_t.
 
 The JPEG library is intended to be used within larger programs.  Furthermore,
 we want it to be reentrant so that it can be used by applications that process
-multiple images concurrently.  The following rules support these retquirements:
+multiple images concurrently.  The following rules support these requirements:
 
 1. Avoid direct use of file I/O, "malloc", error report printouts, etc;
 pass these through the common routines provided.
diff --git a/src/3rdparty/libjpeg/jcapistd.c b/src/3rdparty/libjpeg/jcapistd.c
index 0d43c0575..c0320b1b1 100644
--- a/src/3rdparty/libjpeg/jcapistd.c
+++ b/src/3rdparty/libjpeg/jcapistd.c
@@ -23,7 +23,7 @@
  * Compression initialization.
  * Before calling this, all parameters and a data destination must be set up.
  *
- * We retquire a write_all_tables parameter as a failsafe check when writing
+ * We require a write_all_tables parameter as a failsafe check when writing
  * multiple datastreams from the same compression object.  Since prior runs
  * will have left all the tables marked sent_table=TRUE, a subsequent run
  * would emit an abbreviated stream (no tables) by default.  This may be what
diff --git a/src/3rdparty/libjpeg/jccolor.c b/src/3rdparty/libjpeg/jccolor.c
index c3f0f8dcc..0a8a4b5d1 100644
--- a/src/3rdparty/libjpeg/jccolor.c
+++ b/src/3rdparty/libjpeg/jccolor.c
@@ -123,7 +123,7 @@ rgb_ycc_start (j_compress_ptr cinfo)
  *
  * A starting row offset is provided only for the output buffer.  The caller
  * can easily adjust the passed input_buf value to accommodate any row
- * offset retquired on that side.
+ * offset required on that side.
  */
 
 METHODDEF(void)
diff --git a/src/3rdparty/libjpeg/jchuff.c b/src/3rdparty/libjpeg/jchuff.c
index 45540e607..f23525054 100644
--- a/src/3rdparty/libjpeg/jchuff.c
+++ b/src/3rdparty/libjpeg/jchuff.c
@@ -677,7 +677,7 @@ encode_mcu_gather (j_compress_ptr cinfo, JBLOCKROW *MCU_data)
  * Generate the best Huffman code table for the given counts, fill htbl.
  * Note this is also used by jcphuff.c.
  *
- * The JPEG standard retquires that no symbol be assigned a codeword of all
+ * The JPEG standard requires that no symbol be assigned a codeword of all
  * one bits (so that padding bits added at the end of a compressed segment
  * can't look like a valid code).  Because of the canonical ordering of
  * codewords, this just means that there must be an unused slot in the
@@ -689,7 +689,7 @@ encode_mcu_gather (j_compress_ptr cinfo, JBLOCKROW *MCU_data)
  * practice, because it produces more all-ones bytes (which incur stuffed
  * zero bytes in the final file).  In any case the difference is tiny.
  *
- * The JPEG standard retquires Huffman codes to be no more than 16 bits long.
+ * The JPEG standard requires Huffman codes to be no more than 16 bits long.
  * If some symbols have a very small but nonzero probability, the Huffman tree
  * must be adjusted to meet the code length restriction.  We currently use
  * the adjustment method suggested in JPEG section K.2.  This method is *not*
diff --git a/src/3rdparty/libjpeg/jcmarker.c b/src/3rdparty/libjpeg/jcmarker.c
index 7f5c271f0..4c4cf14a7 100644
--- a/src/3rdparty/libjpeg/jcmarker.c
+++ b/src/3rdparty/libjpeg/jcmarker.c
@@ -582,7 +582,7 @@ write_scan_header (j_compress_ptr cinfo)
     }
   }
 
-  /* Emit DRI if retquired --- note that DRI value could change for each scan.
+  /* Emit DRI if required --- note that DRI value could change for each scan.
    * We avoid wasting space with unnecessary DRIs, however.
    */
   if (cinfo->restart_interval != marker->last_restart_interval) {
diff --git a/src/3rdparty/libjpeg/jcmaster.c b/src/3rdparty/libjpeg/jcmaster.c
index 3b924912c..aab4020b8 100644
--- a/src/3rdparty/libjpeg/jcmaster.c
+++ b/src/3rdparty/libjpeg/jcmaster.c
@@ -243,7 +243,7 @@ validate_script (j_compress_ptr cinfo)
   if (cinfo->progressive_mode) {
 #ifdef C_PROGRESSIVE_SUPPORTED
     /* For progressive mode, we only check that at least some DC data
-     * got sent for each component; the spec does not retquire that all bits
+     * got sent for each component; the spec does not require that all bits
      * of all coefficients be transmitted.  Would it be wiser to enforce
      * transmission of all coefficient bits??
      */
@@ -394,7 +394,7 @@ per_scan_setup (j_compress_ptr cinfo)
  * This is called at the beginning of each pass.  We determine which modules
  * will be active during this pass and give them appropriate start_pass calls.
  * We also set is_last_pass to indicate whether any more passes will be
- * retquired.
+ * required.
  */
 
 METHODDEF(void)
diff --git a/src/3rdparty/libjpeg/jconfig.doc b/src/3rdparty/libjpeg/jconfig.doc
index 4d739bb59..c18d1c064 100644
--- a/src/3rdparty/libjpeg/jconfig.doc
+++ b/src/3rdparty/libjpeg/jconfig.doc
@@ -5,7 +5,7 @@
  * This file is part of the Independent JPEG Group's software.
  * For conditions of distribution and use, see the accompanying README file.
  *
- * This file documents the configuration options that are retquired to
+ * This file documents the configuration options that are required to
  * customize the JPEG software for a particular system.
  *
  * The actual configuration options for a particular installation are stored
diff --git a/src/3rdparty/libjpeg/jconfig.manx b/src/3rdparty/libjpeg/jconfig.manx
index c09b9198e..6dd0d008e 100644
--- a/src/3rdparty/libjpeg/jconfig.manx
+++ b/src/3rdparty/libjpeg/jconfig.manx
@@ -38,6 +38,6 @@
 #undef DONT_USE_B_MODE
 #undef PROGRESS_REPORT		/* optional */
 
-#define signal_catcher _abort	/* hack for Aztec C naming retquirements */
+#define signal_catcher _abort	/* hack for Aztec C naming requirements */
 
 #endif /* JPEG_CJPEG_DJPEG */
diff --git a/src/3rdparty/libjpeg/jconfig.st b/src/3rdparty/libjpeg/jconfig.st
index b5f10f62c..4421b7a1a 100644
--- a/src/3rdparty/libjpeg/jconfig.st
+++ b/src/3rdparty/libjpeg/jconfig.st
@@ -33,7 +33,7 @@
 
 #define TWO_FILE_COMMANDLINE	/* optional -- undef if you like Unix style */
 /* Note: if you undef TWO_FILE_COMMANDLINE, you may need to define
- * USE_SETMODE.  Some Atari compilers retquire it, some do not.
+ * USE_SETMODE.  Some Atari compilers require it, some do not.
  */
 #define NEED_SIGNAL_CATCHER	/* needed if you use jmemname.c */
 #undef DONT_USE_B_MODE
diff --git a/src/3rdparty/libjpeg/jcphuff.c b/src/3rdparty/libjpeg/jcphuff.c
index 4ad2db223..07f9178b0 100644
--- a/src/3rdparty/libjpeg/jcphuff.c
+++ b/src/3rdparty/libjpeg/jcphuff.c
@@ -399,7 +399,7 @@ encode_mcu_DC_first (j_compress_ptr cinfo, JBLOCKROW *MCU_data)
     ci = cinfo->MCU_membership[blkn];
     compptr = cinfo->cur_comp_info[ci];
 
-    /* Compute the DC value after the retquired point transform by Al.
+    /* Compute the DC value after the required point transform by Al.
      * This is simply an arithmetic right shift.
      */
     temp2 = IRIGHT_SHIFT((int) ((*block)[0]), Al);
@@ -669,7 +669,7 @@ encode_mcu_AC_refine (j_compress_ptr cinfo, JBLOCKROW *MCU_data)
       continue;
     }
 
-    /* Emit any retquired ZRLs, but not if they can be folded into EOB */
+    /* Emit any required ZRLs, but not if they can be folded into EOB */
     while (r > 15 && k <= EOB) {
       /* emit any pending EOBRUN and the BE correction bits */
       emit_eobrun(entropy);
diff --git a/src/3rdparty/libjpeg/jcprepct.c b/src/3rdparty/libjpeg/jcprepct.c
index 5c7ad6c08..fa93333db 100644
--- a/src/3rdparty/libjpeg/jcprepct.c
+++ b/src/3rdparty/libjpeg/jcprepct.c
@@ -10,7 +10,7 @@
  * and edge expansion steps.
  *
  * Most of the complexity here is associated with buffering input rows
- * as retquired by the downsampler.  See the comments at the head of
+ * as required by the downsampler.  See the comments at the head of
  * jcsample.c for the downsampler's needs.
  */
 
diff --git a/src/3rdparty/libjpeg/jcsample.c b/src/3rdparty/libjpeg/jcsample.c
index eb31d3648..212ec8757 100644
--- a/src/3rdparty/libjpeg/jcsample.c
+++ b/src/3rdparty/libjpeg/jcsample.c
@@ -285,7 +285,7 @@ h2v2_downsample (j_compress_ptr cinfo, jpeg_component_info * compptr,
 /*
  * Downsample pixel values of a single component.
  * This version handles the standard case of 2:1 horizontal and 2:1 vertical,
- * with smoothing.  One row of context is retquired.
+ * with smoothing.  One row of context is required.
  */
 
 METHODDEF(void)
@@ -385,7 +385,7 @@ h2v2_smooth_downsample (j_compress_ptr cinfo, jpeg_component_info * compptr,
 /*
  * Downsample pixel values of a single component.
  * This version handles the special case of a full-size component,
- * with smoothing.  One row of context is retquired.
+ * with smoothing.  One row of context is required.
  */
 
 METHODDEF(void)
diff --git a/src/3rdparty/libjpeg/jdapimin.c b/src/3rdparty/libjpeg/jdapimin.c
index d19358876..409903a1b 100644
--- a/src/3rdparty/libjpeg/jdapimin.c
+++ b/src/3rdparty/libjpeg/jdapimin.c
@@ -230,7 +230,7 @@ default_decompress_parms (j_decompress_ptr cinfo)
  * requests suspension of the decompressor.  In this case the application
  * should load more source data and then re-call jpeg_read_header to resume
  * processing.
- * If a non-suspending data source is used and retquire_image is TRUE, then the
+ * If a non-suspending data source is used and require_image is TRUE, then the
  * return code need not be inspected since only JPEG_HEADER_OK is possible.
  *
  * This routine is now just a front end to jpeg_consume_input, with some
@@ -238,7 +238,7 @@ default_decompress_parms (j_decompress_ptr cinfo)
  */
 
 GLOBAL(int)
-jpeg_read_header (j_decompress_ptr cinfo, boolean retquire_image)
+jpeg_read_header (j_decompress_ptr cinfo, boolean require_image)
 {
   int retcode;
 
@@ -253,9 +253,9 @@ jpeg_read_header (j_decompress_ptr cinfo, boolean retquire_image)
     retcode = JPEG_HEADER_OK;
     break;
   case JPEG_REACHED_EOI:
-    if (retquire_image)		/* Complain if application wanted an image */
+    if (require_image)		/* Complain if application wanted an image */
       ERREXIT(cinfo, JERR_NO_IMAGE);
-    /* Reset to start state; it would be safer to retquire the application to
+    /* Reset to start state; it would be safer to require the application to
      * call jpeg_abort, but we can't change it now for compatibility reasons.
      * A side effect is to free any temporary memory (there shouldn't be any).
      */
@@ -272,7 +272,7 @@ jpeg_read_header (j_decompress_ptr cinfo, boolean retquire_image)
 
 
 /*
- * Consume data in advance of what the decompressor retquires.
+ * Consume data in advance of what the decompressor requires.
  * This can be called at any time once the decompressor object has
  * been created and a data source has been set up.
  *
diff --git a/src/3rdparty/libjpeg/jdapistd.c b/src/3rdparty/libjpeg/jdapistd.c
index 3df768a97..d23a985e8 100644
--- a/src/3rdparty/libjpeg/jdapistd.c
+++ b/src/3rdparty/libjpeg/jdapistd.c
@@ -100,7 +100,7 @@ output_pass_setup (j_decompress_ptr cinfo)
     cinfo->output_scanline = 0;
     cinfo->global_state = DSTATE_PRESCAN;
   }
-  /* Loop over any retquired dummy passes */
+  /* Loop over any required dummy passes */
   while (cinfo->master->is_dummy_pass) {
 #ifdef TQUANT_2PASS_SUPPORTED
     /* Crank through the dummy pass */
@@ -255,7 +255,7 @@ jpeg_finish_output (j_decompress_ptr cinfo)
   if ((cinfo->global_state == DSTATE_SCANNING ||
        cinfo->global_state == DSTATE_RAW_OK) && cinfo->buffered_image) {
     /* Terminate this pass. */
-    /* We do not retquire the whole pass to have been completed. */
+    /* We do not require the whole pass to have been completed. */
     (*cinfo->master->finish_output_pass) (cinfo);
     cinfo->global_state = DSTATE_BUFPOST;
   } else if (cinfo->global_state != DSTATE_BUFPOST) {
diff --git a/src/3rdparty/libjpeg/jdcolor.c b/src/3rdparty/libjpeg/jdcolor.c
index 94ea3bf95..6c04dfe8a 100644
--- a/src/3rdparty/libjpeg/jdcolor.c
+++ b/src/3rdparty/libjpeg/jdcolor.c
@@ -113,7 +113,7 @@ build_ycc_rgb_table (j_decompress_ptr cinfo)
  * as wide as the input buffer.
  * A starting row offset is provided only for the input buffer.  The caller
  * can easily adjust the passed output_buf value to accommodate any row
- * offset retquired on that side.
+ * offset required on that side.
  */
 
 METHODDEF(void)
diff --git a/src/3rdparty/libjpeg/jdct.h b/src/3rdparty/libjpeg/jdct.h
index ebaf73013..2fd3ffcda 100644
--- a/src/3rdparty/libjpeg/jdct.h
+++ b/src/3rdparty/libjpeg/jdct.h
@@ -68,7 +68,7 @@ typedef FAST_FLOAT FLOAT_MULT_TYPE; /* preferred floating type */
  * Each IDCT routine is responsible for range-limiting its results and
  * converting them to unsigned form (0..MAXJSAMPLE).  The raw outputs could
  * be quite far out of range if the input data is corrupt, so a bulletproof
- * range-limiting step is retquired.  We use a mask-and-table-lookup method
+ * range-limiting step is required.  We use a mask-and-table-lookup method
  * to do the combined operations tquickly.  See the comments with
  * prepare_range_limit_table (in jdmaster.c) for more info.
  */
diff --git a/src/3rdparty/libjpeg/jddctmgr.c b/src/3rdparty/libjpeg/jddctmgr.c
index 28f7b039a..9d80fe9e9 100644
--- a/src/3rdparty/libjpeg/jddctmgr.c
+++ b/src/3rdparty/libjpeg/jddctmgr.c
@@ -67,7 +67,7 @@ typedef union {
 } multiplier_table;
 
 
-/* The current scaled-IDCT routines retquire ISLOW-style multiplier tables,
+/* The current scaled-IDCT routines require ISLOW-style multiplier tables,
  * so be sure to compile that code if either ISLOW or SCALING is requested.
  */
 #ifdef DCT_ISLOW_SUPPORTED
diff --git a/src/3rdparty/libjpeg/jdhuff.c b/src/3rdparty/libjpeg/jdhuff.c
index a8587242b..d99f9e7ca 100644
--- a/src/3rdparty/libjpeg/jdhuff.c
+++ b/src/3rdparty/libjpeg/jdhuff.c
@@ -252,7 +252,7 @@ jpeg_make_d_derived_tbl (j_decompress_ptr cinfo, boolean isDC, int tblno,
 
   /* Validate symbols as being reasonable.
    * For AC tables, we make no check, but accept all byte values 0..255.
-   * For DC tables, we retquire the symbols to be in range 0..15.
+   * For DC tables, we require the symbols to be in range 0..15.
    * (Tighter bounds could be applied depending on the data depth and mode,
    * but this is sufficient to ensure safe decoding.)
    */
diff --git a/src/3rdparty/libjpeg/jdmainct.c b/src/3rdparty/libjpeg/jdmainct.c
index c5db1489a..c9a48fe11 100644
--- a/src/3rdparty/libjpeg/jdmainct.c
+++ b/src/3rdparty/libjpeg/jdmainct.c
@@ -27,7 +27,7 @@
  *
  * Postprocessor input data is counted in "row groups".  A row group
  * is defined to be (v_samp_factor * DCT_scaled_size / min_DCT_scaled_size)
- * sample rows of each component.  (We retquire DCT_scaled_size values to be
+ * sample rows of each component.  (We require DCT_scaled_size values to be
  * chosen such that these numbers are integers.  In practice DCT_scaled_size
  * values will likely be powers of two, so we actually have the stronger
  * condition that DCT_scaled_size / min_DCT_scaled_size is an integer.)
@@ -45,7 +45,7 @@
  *
  * Depending on the vertical scaling algorithm used, the upsampler may need
  * access to the sample row(s) above and below its current input row group.
- * The upsampler is retquired to set need_context_rows TRUE at global selection
+ * The upsampler is required to set need_context_rows TRUE at global selection
  * time if so.  When need_context_rows is FALSE, this controller can simply
  * obtain one iMCU row at a time from the coefficient controller and dole it
  * out as row groups to the postprocessor.
@@ -54,7 +54,7 @@
  * passed to postprocessing contains at least one row group's worth of samples
  * above and below the row group(s) being processed.  Note that the context
  * rows "above" the first passed row group appear at negative row offsets in
- * the passed buffer.  At the top and bottom of the image, the retquired
+ * the passed buffer.  At the top and bottom of the image, the required
  * context rows are manufactured by duplicating the first or last real sample
  * row; this avoids having special cases in the upsampling inner loops.
  *
@@ -90,7 +90,7 @@
  *                    0                            0
  * We read alternate iMCU rows using each master pointer; thus the last two
  * row groups of the previous iMCU row remain un-overwritten in the workspace.
- * The pointer lists are set up so that the retquired context rows appear to
+ * The pointer lists are set up so that the required context rows appear to
  * be adjacent to the proper places when we pass the pointer lists to the
  * upsampler.
  *
@@ -338,7 +338,7 @@ start_pass_main (j_decompress_ptr cinfo, J_BUF_MODE pass_mode)
 
 /*
  * Process some data.
- * This handles the simple case where no context is retquired.
+ * This handles the simple case where no context is required.
  */
 
 METHODDEF(void)
diff --git a/src/3rdparty/libjpeg/jdmarker.c b/src/3rdparty/libjpeg/jdmarker.c
index 58ea5b5df..048dfc7ae 100644
--- a/src/3rdparty/libjpeg/jdmarker.c
+++ b/src/3rdparty/libjpeg/jdmarker.c
@@ -189,7 +189,7 @@ typedef my_marker_reader * my_marker_ptr;
  *
  * Note that we don't bother to avoid duplicate trace messages if a
  * suspension occurs within marker parameters.  Other side effects
- * retquire more care.
+ * require more care.
  */
 
 
@@ -954,7 +954,7 @@ read_markers (j_decompress_ptr cinfo)
   /* Outer loop repeats once for each marker. */
   for (;;) {
     /* Collect the marker proper, unless we already did. */
-    /* NB: first_marker() enforces the retquirement that SOI appear first. */
+    /* NB: first_marker() enforces the requirement that SOI appear first. */
     if (cinfo->unread_marker == 0) {
       if (! cinfo->marker->saw_SOI) {
 	if (! first_marker(cinfo))
@@ -1100,7 +1100,7 @@ read_markers (j_decompress_ptr cinfo)
 /*
  * Read a restart marker, which is expected to appear next in the datastream;
  * if the marker is not there, take appropriate recovery action.
- * Returns FALSE if suspension is retquired.
+ * Returns FALSE if suspension is required.
  *
  * This is called by the entropy decoder after it has read an appropriate
  * number of MCUs.  cinfo->unread_marker may be nonzero if the entropy decoder
@@ -1156,7 +1156,7 @@ read_restart_marker (j_decompress_ptr cinfo)
  * Note that cinfo->unread_marker is treated as a marker appearing before
  * the current data-source input point; usually it should be reset to zero
  * before returning.
- * Returns FALSE if suspension is retquired.
+ * Returns FALSE if suspension is required.
  *
  * This implementation is substantially constrained by wanting to treat the
  * input as a data stream; this means we can't back up.  Therefore, we have
@@ -1312,7 +1312,7 @@ jpeg_save_markers (j_decompress_ptr cinfo, int marker_code,
     length_limit = (unsigned int) maxlength;
 
   /* Choose processor routine to use.
-   * APP0/APP14 have special retquirements.
+   * APP0/APP14 have special requirements.
    */
   if (length_limit) {
     processor = save_marker;
diff --git a/src/3rdparty/libjpeg/jdpostct.c b/src/3rdparty/libjpeg/jdpostct.c
index dadbbde35..e6838c734 100644
--- a/src/3rdparty/libjpeg/jdpostct.c
+++ b/src/3rdparty/libjpeg/jdpostct.c
@@ -10,7 +10,7 @@
  * quantization/reduction steps; specifically, it controls the buffering
  * between upsample/color conversion and color quantization/reduction.
  *
- * If no color quantization/reduction is retquired, then this module has no
+ * If no color quantization/reduction is required, then this module has no
  * work to do, and it just hands off to the upsample/color conversion code.
  * An integrated upsample/convert/quantize process would replace this module
  * entirely.
diff --git a/src/3rdparty/libjpeg/jfdctint.c b/src/3rdparty/libjpeg/jfdctint.c
index 3a9055c4c..0a78b64ae 100644
--- a/src/3rdparty/libjpeg/jfdctint.c
+++ b/src/3rdparty/libjpeg/jfdctint.c
@@ -65,7 +65,7 @@
  *
  * The outputs of the first pass are scaled up by PASS1_BITS bits so that
  * they are represented to better-than-integral precision.  These outputs
- * retquire BITS_IN_JSAMPLE + PASS1_BITS + 3 bits; this fits in a 16-bit word
+ * require BITS_IN_JSAMPLE + PASS1_BITS + 3 bits; this fits in a 16-bit word
  * with the recommended scaling.  (For 12-bit sample data, the intermediate
  * array is INT32 anyway.)
  *
diff --git a/src/3rdparty/libjpeg/jidctint.c b/src/3rdparty/libjpeg/jidctint.c
index a85e99959..1f5f39309 100644
--- a/src/3rdparty/libjpeg/jidctint.c
+++ b/src/3rdparty/libjpeg/jidctint.c
@@ -65,7 +65,7 @@
  *
  * The outputs of the first pass are scaled up by PASS1_BITS bits so that
  * they are represented to better-than-integral precision.  These outputs
- * retquire BITS_IN_JSAMPLE + PASS1_BITS + 3 bits; this fits in a 16-bit word
+ * require BITS_IN_JSAMPLE + PASS1_BITS + 3 bits; this fits in a 16-bit word
  * with the recommended scaling.  (To scale up 12-bit sample data further, an
  * intermediate INT32 array would be needed.)
  *
diff --git a/src/3rdparty/libjpeg/jinclude.h b/src/3rdparty/libjpeg/jinclude.h
index 981650f64..0a4f15146 100644
--- a/src/3rdparty/libjpeg/jinclude.h
+++ b/src/3rdparty/libjpeg/jinclude.h
@@ -25,7 +25,7 @@
  * On an ANSI-conforming system it is sufficient to include <stddef.h>.
  * Otherwise, we get them from <stdlib.h> or <stdio.h>; we may have to
  * pull in <sys/types.h> as well.
- * Note that the core JPEG library does not retquire <stdio.h>;
+ * Note that the core JPEG library does not require <stdio.h>;
  * only the default error handler and data source/destination modules do.
  * But we must pull it in because of the references to FILE in jpeglib.h.
  * You can remove those references if you want to compile without <stdio.h>.
diff --git a/src/3rdparty/libjpeg/jmemmgr.c b/src/3rdparty/libjpeg/jmemmgr.c
index 99146731a..d801b322d 100644
--- a/src/3rdparty/libjpeg/jmemmgr.c
+++ b/src/3rdparty/libjpeg/jmemmgr.c
@@ -51,12 +51,12 @@ extern char * getenv JPP((const char * name));
 
 
 /*
- * Many machines retquire storage alignment: longs must start on 4-byte
+ * Many machines require storage alignment: longs must start on 4-byte
  * boundaries, doubles on 8-byte boundaries, etc.  On such machines, malloc()
  * always returns pointers that are multiples of the worst-case alignment
- * retquirement, and we had better do so too.
+ * requirement, and we had better do so too.
  * There isn't any really portable way to determine the worst-case alignment
- * retquirement.  This module assumes that the alignment retquirement is
+ * requirement.  This module assumes that the alignment requirement is
  * multiples of sizeof(ALIGN_TYPE).
  * By default, we define ALIGN_TYPE as double.  This is necessary on some
  * workstations (where doubles really do need 8-byte alignment) and will work
@@ -83,7 +83,7 @@ extern char * getenv JPP((const char * name));
  * link pointer must be FAR on 80x86 machines.
  * Notice that the "real" header fields are union'ed with a dummy ALIGN_TYPE
  * field.  This forces the compiler to make SIZEOF(small_pool_hdr) a multiple
- * of the alignment retquirement of ALIGN_TYPE.
+ * of the alignment requirement of ALIGN_TYPE.
  */
 
 typedef union small_pool_struct * small_pool_ptr;
@@ -1036,7 +1036,7 @@ jinit_memory_mgr (j_common_ptr cinfo)
 
   /* Check for configuration errors.
    * SIZEOF(ALIGN_TYPE) should be a power of 2; otherwise, it probably
-   * doesn't reflect any real hardware alignment retquirement.
+   * doesn't reflect any real hardware alignment requirement.
    * The test is a little tricky: for X>0, X and X-1 have no one-bits
    * in common if and only if X is a power of 2, ie has only one one-bit.
    * Some compilers may give an "unreachable code" warning here; ignore it.
diff --git a/src/3rdparty/libjpeg/jmemnobs.c b/src/3rdparty/libjpeg/jmemnobs.c
index 4167b453b..eb8c33772 100644
--- a/src/3rdparty/libjpeg/jmemnobs.c
+++ b/src/3rdparty/libjpeg/jmemnobs.c
@@ -7,7 +7,7 @@
  *
  * This file provides a really simple implementation of the system-
  * dependent portion of the JPEG memory manager.  This implementation
- * assumes that no backing-store files are needed: all retquired space
+ * assumes that no backing-store files are needed: all required space
  * can be obtained from malloc().
  * This is very portable in the sense that it'll compile on almost anything,
  * but you'd better have lots of main memory (or virtual memory) if you want
@@ -93,7 +93,7 @@ jpeg_open_backing_store (j_common_ptr cinfo, backing_store_ptr info,
 
 /*
  * These routines take care of any system-dependent initialization and
- * cleanup retquired.  Here, there isn't any.
+ * cleanup required.  Here, there isn't any.
  */
 
 GLOBAL(long)
diff --git a/src/3rdparty/libjpeg/jmemsys.h b/src/3rdparty/libjpeg/jmemsys.h
index 617f72f1d..6c3c6d348 100644
--- a/src/3rdparty/libjpeg/jmemsys.h
+++ b/src/3rdparty/libjpeg/jmemsys.h
@@ -83,7 +83,7 @@ EXTERN(void) jpeg_free_large JPP((j_common_ptr cinfo, void FAR * object,
  * jpeg_get_large.  If more space than this is needed, backing store will be
  * used.  NOTE: any memory already allocated must not be counted.
  *
- * There is a minimum space retquirement, corresponding to the minimum
+ * There is a minimum space requirement, corresponding to the minimum
  * feasible buffer sizes; jmemmgr.c will request that much space even if
  * jpeg_mem_available returns zero.  The maximum space needed, enough to hold
  * all working storage in memory, is also passed in case it is useful.
@@ -184,7 +184,7 @@ EXTERN(void) jpeg_open_backing_store JPP((j_common_ptr cinfo,
 
 /*
  * These routines take care of any system-dependent initialization and
- * cleanup retquired.  jpeg_mem_init will be called before anything is
+ * cleanup required.  jpeg_mem_init will be called before anything is
  * allocated (and, therefore, nothing in cinfo is of use except the error
  * manager pointer).  It should return a suitable default value for
  * max_memory_to_use; this may subsequently be overridden by the surrounding
diff --git a/src/3rdparty/libjpeg/jmorecfg.h b/src/3rdparty/libjpeg/jmorecfg.h
index f4a1bd5dd..58dec612a 100644
--- a/src/3rdparty/libjpeg/jmorecfg.h
+++ b/src/3rdparty/libjpeg/jmorecfg.h
@@ -177,7 +177,7 @@ typedef unsigned int JDIMENSION;
  * You could modify them if you need to change function linkage conventions;
  * in particular, you'll need to do that to make the library a Windows DLL.
  * Another application is to make all functions global for use with debuggers
- * or code profilers that retquire it.
+ * or code profilers that require it.
  */
 
 /* a function called through method pointers: */
diff --git a/src/3rdparty/libjpeg/jpegint.h b/src/3rdparty/libjpeg/jpegint.h
index 73d6f93a5..95b00d405 100644
--- a/src/3rdparty/libjpeg/jpegint.h
+++ b/src/3rdparty/libjpeg/jpegint.h
@@ -15,7 +15,7 @@
 
 typedef enum {			/* Operating modes for buffer controllers */
 	JBUF_PASS_THRU,		/* Plain stripwise operation */
-	/* Remaining modes retquire a full-image buffer to have been created */
+	/* Remaining modes require a full-image buffer to have been created */
 	JBUF_SAVE_SOURCE,	/* Run source subobject only, save output */
 	JBUF_CRANK_DEST,	/* Run dest subobject only, using saved data */
 	JBUF_SAVE_AND_PASS	/* Run both subobjects, save output */
diff --git a/src/3rdparty/libjpeg/jpeglib.h b/src/3rdparty/libjpeg/jpeglib.h
index 9f1401e84..8a9631f1d 100644
--- a/src/3rdparty/libjpeg/jpeglib.h
+++ b/src/3rdparty/libjpeg/jpeglib.h
@@ -811,7 +811,7 @@ typedef JMETHOD(boolean, jpeg_marker_parser_method, (j_decompress_ptr cinfo));
 
 /* Declarations for routines called by application.
  * The JPP macro hides prototype parameters from compilers that can't cope.
- * Note JPP retquires double parentheses.
+ * Note JPP requires double parentheses.
  */
 
 #ifdef HAVE_PROTOTYPES
@@ -960,12 +960,12 @@ EXTERN(void) jpeg_write_tables JPP((j_compress_ptr cinfo));
 
 /* Decompression startup: read start of JPEG datastream to see what's there */
 EXTERN(int) jpeg_read_header JPP((j_decompress_ptr cinfo,
-				  boolean retquire_image));
+				  boolean require_image));
 /* Return value is one of: */
 #define JPEG_SUSPENDED		0 /* Suspended due to lack of input data */
 #define JPEG_HEADER_OK		1 /* Found valid image datastream */
 #define JPEG_HEADER_TABLES_ONLY	2 /* Found valid table-specs-only datastream */
-/* If you pass retquire_image = TRUE (normal case), you need not check for
+/* If you pass require_image = TRUE (normal case), you need not check for
  * a TABLES_ONLY return code; an abbreviated file will cause an error exit.
  * JPEG_SUSPENDED is only possible if you use a data source module that can
  * give a suspension return (the stdio source module doesn't).
diff --git a/src/3rdparty/libjpeg/jquant1.c b/src/3rdparty/libjpeg/jquant1.c
index 28e9e60df..89fbf7497 100644
--- a/src/3rdparty/libjpeg/jquant1.c
+++ b/src/3rdparty/libjpeg/jquant1.c
@@ -546,7 +546,7 @@ quantize_ord_dither (j_decompress_ptr cinfo, JSAMPARRAY input_buf,
 	 * Range-limiting need not be done explicitly, as we have extended
 	 * the colorindex table to produce the right answers for out-of-range
 	 * inputs.  The maximum dither is +- MAXJSAMPLE; this sets the
-	 * retquired amount of padding.
+	 * required amount of padding.
 	 */
 	*output_ptr += colorindex_ci[GETJSAMPLE(*input_ptr)+dither[col_index]];
 	input_ptr += nc;
@@ -671,7 +671,7 @@ quantize_fs_dither (j_decompress_ptr cinfo, JSAMPARRAY input_buf,
 	 */
 	cur = RIGHT_SHIFT(cur + errorptr[dir] + 8, 4);
 	/* Form pixel value + error, and range-limit to 0..MAXJSAMPLE.
-	 * The maximum error is +- MAXJSAMPLE; this sets the retquired size
+	 * The maximum error is +- MAXJSAMPLE; this sets the required size
 	 * of the range_limit array.
 	 */
 	cur += GETJSAMPLE(*input_ptr);
diff --git a/src/3rdparty/libjpeg/jquant2.c b/src/3rdparty/libjpeg/jquant2.c
index 06671126c..24d3cc219 100644
--- a/src/3rdparty/libjpeg/jquant2.c
+++ b/src/3rdparty/libjpeg/jquant2.c
@@ -44,7 +44,7 @@
  * 
  * The second pass over the image maps each input pixel to the closest output
  * color (optionally after applying a Floyd-Steinberg dithering correction).
- * This mapping is logically trivial, but making it go fast enough retquires
+ * This mapping is logically trivial, but making it go fast enough requires
  * considerable care.
  *
  * Heckbert-style quantizers vary a good deal in their policies for choosing
@@ -215,7 +215,7 @@ typedef my_cquantizer * my_cquantize_ptr;
  * Prescan some rows of pixels.
  * In this module the prescan simply updates the histogram, which has been
  * initialized to zeroes by start_pass.
- * An output_buf parameter is retquired by the method signature, but no data
+ * An output_buf parameter is required by the method signature, but no data
  * is actually output (in fact the buffer controller is probably passing a
  * NULL pointer).
  */
@@ -1015,7 +1015,7 @@ pass2_fs_dither (j_decompress_ptr cinfo,
       cur2 = error_limit[cur2];
       /* Form pixel value + error, and range-limit to 0..MAXJSAMPLE.
        * The maximum error is +- MAXJSAMPLE (or less with error limiting);
-       * this sets the retquired size of the range_limit array.
+       * this sets the required size of the range_limit array.
        */
       cur0 += GETJSAMPLE(inptr[0]);
       cur1 += GETJSAMPLE(inptr[1]);
@@ -1269,7 +1269,7 @@ jinit_2pass_quantizer (j_decompress_ptr cinfo)
   }
   cquantize->needs_zeroed = TRUE; /* histogram is garbage now */
 
-  /* Allocate storage for the completed colormap, if retquired.
+  /* Allocate storage for the completed colormap, if required.
    * We do this now since it is FAR storage and may affect
    * the memory manager's space calculations.
    */
diff --git a/src/3rdparty/libjpeg/libjpeg.doc b/src/3rdparty/libjpeg/libjpeg.doc
index 95da39e78..d8fb38759 100644
--- a/src/3rdparty/libjpeg/libjpeg.doc
+++ b/src/3rdparty/libjpeg/libjpeg.doc
@@ -84,7 +84,7 @@ provides multiple implementations that cover most of the useful tradeoffs,
 ranging from very-high-quality down to fast-preview operation.  On the
 compression side we have generally not provided low-quality choices, since
 compression is normally less time-critical.  It should be understood that the
-low-quality modes may not meet the JPEG standard's accuracy retquirements;
+low-quality modes may not meet the JPEG standard's accuracy requirements;
 nonetheless, they are useful for viewers.
 
 A word about functions *not* provided by the library.  We handle a subset of
@@ -379,7 +379,7 @@ the compression cycle.
 5. while (scan lines remain to be written)
 	jpeg_write_scanlines(...);
 
-Now write all the retquired image data by calling jpeg_write_scanlines()
+Now write all the required image data by calling jpeg_write_scanlines()
 one or more times.  You can pass one or more scanlines in each call, up
 to the total image height.  In most applications it is convenient to pass
 just one or a few scanlines at a time.  The expected format for the passed
@@ -496,7 +496,7 @@ in either of two ways:
   This will return the object to an idle state, releasing any working memory.
   jpeg_abort() is allowed at any time after successful object creation.
 
-Note that cleaning up the data destination, if retquired, is your
+Note that cleaning up the data destination, if required, is your
 responsibility; neither of these routines will call term_destination().
 (See "Compressed data handling", below, for more about that.)
 
@@ -645,7 +645,7 @@ You will need output_width * output_components JSAMPLEs per scanline in your
 output buffer, and a total of output_height scanlines will be returned.
 
 Note: if you are using the JPEG library's internal memory manager to allocate
-data buffers (as djpeg does), then the manager's protocol retquires that you
+data buffers (as djpeg does), then the manager's protocol requires that you
 request large buffers *before* calling jpeg_start_decompress().  This is a
 little tricky since the output_XXX fields are not normally valid then.  You
 can make them valid by calling jpeg_calc_output_dimensions() after setting the
@@ -770,10 +770,10 @@ it will try to grab extended memory for temp files, and that space will NOT be
 freed automatically.  See cjpeg.c or djpeg.c for an example signal handler.
 
 It may be worth pointing out that the core JPEG library does not actually
-retquire the stdio library: only the default source/destination managers and
+require the stdio library: only the default source/destination managers and
 error handler need it.  You can use the library in a stdio-less environment
 if you replace those modules and use jmemnobs.c (or another memory manager of
-your own devising).  More info about the minimum system library retquirements
+your own devising).  More info about the minimum system library requirements
 may be found in jinclude.h.
 
 
@@ -785,7 +785,7 @@ Compression parameter selection
 
 This section describes all the optional parameters you can set for JPEG
 compression, as well as the "helper" routines provided to assist in this
-task.  Proper setting of some parameters retquires detailed understanding
+task.  Proper setting of some parameters requires detailed understanding
 of the JPEG standard; if you don't know what a parameter is for, it's best
 not to mess with it!  See REFERENCES in the README file for pointers to
 more info about JPEG.
@@ -897,7 +897,7 @@ int num_components
 
 boolean optimize_coding
 	TRUE causes the compressor to compute optimal Huffman coding tables
-	for the image.  This retquires an extra pass over the data and
+	for the image.  This requires an extra pass over the data and
 	therefore costs a good deal of space and time.  The default is
 	FALSE, which tells the compressor to use the supplied or default
 	Huffman tables.  In most cases optimal tables save only a few percent
@@ -1168,7 +1168,7 @@ int rec_outbuf_height		Recommended height of scanline buffer.
 
 When quantizing colors, output_components is 1, indicating a single color map
 index per pixel.  Otherwise it equals out_color_components.  The output arrays
-are retquired to be output_width * output_components JSAMPLEs wide.
+are required to be output_width * output_components JSAMPLEs wide.
 
 rec_outbuf_height is the recommended minimum height (in scanlines) of the
 buffer passed to jpeg_read_scanlines().  If the buffer is smaller, the
@@ -1568,7 +1568,7 @@ regenerated after resumption.
 
 Because of the backtracking behavior, a good-size output buffer is essential
 for efficiency; you don't want the compressor to suspend often.  (In fact, an
-overly small buffer could lead to infinite looping, if a single MCU retquired
+overly small buffer could lead to infinite looping, if a single MCU required
 more data than would fit in the buffer.)  We recommend a buffer of at least
 several Kbytes.  You may want to insert explicit code to ensure that you don't
 call jpeg_write_scanlines() unless there is a reasonable amount of space in
@@ -1624,7 +1624,7 @@ for decent performance; furthermore, you should load a reasonable amount of
 new data before resuming decompression.  (If you loaded, say, only one new
 byte each time around, you could waste a LOT of cycles.)
 
-The skip_input_data() source manager routine retquires special care in a
+The skip_input_data() source manager routine requires special care in a
 suspension scenario.  This routine is NOT granted the ability to suspend the
 decompressor; it can decrement bytes_in_buffer to zero, but no more.  If the
 requested skip distance exceeds the amount of data currently in the input
@@ -1693,7 +1693,7 @@ with the case of skipping not-yet-received data, however.
 It's much simpler to use only a single buffer; when fill_input_buffer() is
 called, move any unconsumed data (beyond the current pointer/count) down to
 the beginning of this buffer and then load new data into the remaining buffer
-space.  This approach retquires a little more data copying but is far easier
+space.  This approach requires a little more data copying but is far easier
 to get right.
 
 
@@ -1721,7 +1721,7 @@ To perform incremental display, an application needs to use the decoder
 library's "buffered-image" mode, in which it receives a decoded image
 multiple times.
 
-Each displayed scan retquires about as much work to decode as a full JPEG
+Each displayed scan requires about as much work to decode as a full JPEG
 image of the same size, so the decoder must be fairly fast in relation to the
 data transmission rate in order to make incremental display useful.  However,
 it is possible to skip displaying the image and simply add the incoming bits
@@ -1791,7 +1791,7 @@ The basic control flow for buffered-image decoding is
 	cinfo.buffered_image = TRUE;	/* select buffered-image mode */
 	jpeg_start_decompress()
 	for (each output pass) {
-	    adjust output decompression parameters if retquired
+	    adjust output decompression parameters if required
 	    jpeg_start_output()		/* start a new output pass */
 	    for (all scanlines in image) {
 	        jpeg_read_scanlines()
@@ -1855,14 +1855,14 @@ immediately return JPEG_REACHED_EOI without attempting to read more data.)
 
 The library's output processing will automatically call jpeg_consume_input()
 whenever the output processing overtakes the input; thus, simple lockstep
-display retquires no direct calls to jpeg_consume_input().  But by adding
+display requires no direct calls to jpeg_consume_input().  But by adding
 calls to jpeg_consume_input(), you can absorb data in advance of what is
 being displayed.  This has two benefits:
   * You can limit buildup of unprocessed data in your input buffer.
   * You can eliminate extra display passes by paying attention to the
     state of the library's input processing.
 
-The first of these benefits only retquires interspersing calls to
+The first of these benefits only requires interspersing calls to
 jpeg_consume_input() with your display operations and any other processing
 you may be doing.  To avoid wasting cycles due to backtracking, it's best to
 call jpeg_consume_input() only after a hundred or so new bytes have arrived.
@@ -1926,7 +1926,7 @@ something like this:
 	do {
 	    absorb any waiting input by calling jpeg_consume_input()
 	    final_pass = jpeg_input_complete(&cinfo);
-	    adjust output decompression parameters if retquired
+	    adjust output decompression parameters if required
 	    jpeg_start_output(&cinfo, cinfo.input_scan_number);
 	    ...
 	    jpeg_finish_output()
@@ -2029,7 +2029,7 @@ allowed after jpeg_start_decompress() is called:
   up on smooth gradients until the lowest coefficient bits are sent.
 * Color quantization mode can be changed under the rules described below.
   You *cannot* change between full-color and quantized output (because that
-  would alter the retquired I/O buffer sizes), but you can change which
+  would alter the required I/O buffer sizes), but you can change which
   quantization method is used.
 
 When generating color-quantized output, changing quantization method is a
@@ -2048,9 +2048,9 @@ These methods offer successively better quality and lesser speed.  However,
 only the first method is available for quantizing in non-RGB color spaces.
 
 IMPORTANT: because the different quantizer methods have very different
-working-storage retquirements, the library retquires you to indicate which
+working-storage requirements, the library requires you to indicate which
 one(s) you intend to use before you call jpeg_start_decompress().  (If we did
-not retquire this, the max_memory_to_use setting would be a complete fiction.)
+not require this, the max_memory_to_use setting would be a complete fiction.)
 You do this by setting one or more of these three cinfo fields to TRUE:
 	enable_1pass_quant		Fixed color cube colormap
 	enable_external_quant		Externally-supplied colormap
@@ -2073,7 +2073,7 @@ special rules apply:
 NOTE: if you want to use the same colormap as was used in the prior pass,
 you should not do either of these things.  This will save some nontrivial
 switchover costs.
-(These retquirements exist because cinfo.colormap will always be non-NULL
+(These requirements exist because cinfo.colormap will always be non-NULL
 after completing a prior output pass, since both the 1-pass and 2-pass
 quantizers set it to point to their output colormaps.  Thus you have to
 do one of these two things to notify the library that something has changed.
@@ -2269,7 +2269,7 @@ into it, as illustrated above.  Ditto for Huffman tables, of course.)
 You might want to read the tables from a tables-only file, rather than
 hard-wiring them into your application.  The jpeg_read_header() call is
 sufficient to read a tables-only file.  You must pass a second parameter of
-FALSE to indicate that you do not retquire an image to be present.  Thus, the
+FALSE to indicate that you do not require an image to be present.  Thus, the
 typical scenario is
 
 	create JPEG decompression object
@@ -2474,7 +2474,7 @@ Raw (downsampled) image data
 
 Some applications need to supply already-downsampled image data to the JPEG
 compressor, or to receive raw downsampled data from the decompressor.  The
-library supports this retquirement by allowing the application to write or
+library supports this requirement by allowing the application to write or
 read raw data, bypassing the normal preprocessing or postprocessing steps.
 The interface is different from the standard one and is somewhat harder to
 use.  If your interest is merely in bypassing color conversion, we recommend
@@ -2529,7 +2529,7 @@ be exactly that amount (or possibly some multiple of that amount, in future
 library versions).  This is true even on the last call at the bottom of the
 image; don't forget to pad your data as necessary.
 
-The retquired dimensions of the supplied data can be computed for each
+The required dimensions of the supplied data can be computed for each
 component as
 	cinfo->comp_info[i].width_in_blocks*DCTSIZE  samples per row
 	cinfo->comp_info[i].height_in_blocks*DCTSIZE rows in image
@@ -2771,10 +2771,10 @@ Use alloc_large instead of alloc_small for anything bigger than a few Kbytes.
 There are also alloc_sarray and alloc_barray routines that automatically
 build 2-D sample or block arrays.
 
-The library's minimum space retquirements to process an image depend on the
+The library's minimum space requirements to process an image depend on the
 image's width, but not on its height, because the library ordinarily works
 with "strip" buffers that are as wide as the image but just a few rows high.
-Some operating modes (eg, two-pass color quantization) retquire full-image
+Some operating modes (eg, two-pass color quantization) require full-image
 buffers.  Such buffers are treated as "virtual arrays": only the current strip
 need be in memory, and the rest can be swapped out to a temporary file.
 
@@ -2801,7 +2801,7 @@ If you use the jmemname.c or jmemdos.c memory manager back end, it is
 important to clean up the JPEG object properly to ensure that the temporary
 files get deleted.  (This is especially crucial with jmemdos.c, where the
 "temporary files" may be extended-memory segments; if they are not freed,
-DOS will retquire a reboot to recover the memory.)  Thus, with these memory
+DOS will require a reboot to recover the memory.)  Thus, with these memory
 managers, it's a good idea to provide a signal handler that will trap any
 early exit from your program.  The handler should call either jpeg_abort()
 or jpeg_destroy() for any active JPEG objects.  A handler is not needed with
@@ -2813,11 +2813,11 @@ tmpfile().
 Memory usage
 ------------
 
-Working memory retquirements while performing compression or decompression
+Working memory requirements while performing compression or decompression
 depend on image dimensions, image characteristics (such as colorspace and
 JPEG process), and operating mode (application-selected options).
 
-As of v6b, the decompressor retquires:
+As of v6b, the decompressor requires:
  1. About 24K in more-or-less-fixed-size data.  This varies a bit depending
     on operating mode and image characteristics (particularly color vs.
     grayscale), but it doesn't depend on image dimensions.
@@ -2828,7 +2828,7 @@ As of v6b, the decompressor retquires:
  3. A full-image DCT coefficient buffer is needed to decode a multi-scan JPEG
     file (including progressive JPEGs), or whenever you select buffered-image
     mode.  This takes 2 bytes/coefficient.  At typical 2x2 sampling, that's
-    3 bytes per pixel for a color image.  Worst case (1x1 sampling) retquires
+    3 bytes per pixel for a color image.  Worst case (1x1 sampling) requires
     6 bytes/pixel.  For grayscale, figure 2 bytes/pixel.
  4. To perform 2-pass color quantization, the decompressor also needs a
     128K color lookup table and a full-image pixel buffer (3 bytes/pixel).
@@ -2839,7 +2839,7 @@ The above figures are valid for 8-bit JPEG data precision and a machine with
 32-bit ints.  For 12-bit JPEG data, double the size of the strip buffers and
 quantization pixel buffer.  The "fixed-size" data will be somewhat smaller
 with 16-bit ints, larger with 64-bit ints.  Also, CMYK or other unusual
-color spaces will retquire different amounts of space.
+color spaces will require different amounts of space.
 
 The full-image coefficient and pixel buffers, if needed at all, do not
 have to be fully RAM resident; you can have the library use temporary
@@ -2847,7 +2847,7 @@ files instead when the total memory usage would exceed a limit you set.
 (But if your OS supports virtual memory, it's probably better to just use
 jmemnobs and let the OS do the swapping.)
 
-The compressor's memory retquirements are similar, except that it has no need
+The compressor's memory requirements are similar, except that it has no need
 for color quantization.  Also, it needs a full-image DCT coefficient buffer
 if Huffman-table optimization is asked for, even if progressive mode is not
 requested.
@@ -2928,7 +2928,7 @@ distributed, we make the assumptions that
 	short	is at least 16 bits wide
 	int	is at least 16 bits wide
 	long	is at least 32 bits wide
-(These are the minimum retquirements of the ANSI C standard.)  Wider types will
+(These are the minimum requirements of the ANSI C standard.)  Wider types will
 work fine, although memory may be used inefficiently if char is much larger
 than 8 bits or short is much bigger than 16 bits.  The code should work
 equally well with 16- or 32-bit ints.
@@ -2996,7 +2996,7 @@ save a JPEG object between compression or decompression operations.
 Far data space may also be a tight resource when you are dealing with large
 images.  The most memory-intensive case is decompression with two-pass color
 quantization, or single-pass quantization to an externally supplied color
-map.  This retquires a 128Kb color lookup table plus strip buffers amounting
+map.  This requires a 128Kb color lookup table plus strip buffers amounting
 to about 40 bytes per column for typical sampling ratios (eg, about 25600
 bytes for a 640-pixel-wide image).  You may not be able to process wide
 images if you have large data structures of your own.
diff --git a/src/3rdparty/libjpeg/structure.doc b/src/3rdparty/libjpeg/structure.doc
index b9b20cc83..51c9def7e 100644
--- a/src/3rdparty/libjpeg/structure.doc
+++ b/src/3rdparty/libjpeg/structure.doc
@@ -81,13 +81,13 @@ provides multiple implementations that cover most of the useful tradeoffs,
 ranging from very-high-quality down to fast-preview operation.  On the
 compression side we have generally not provided low-quality choices, since
 compression is normally less time-critical.  It should be understood that the
-low-quality modes may not meet the JPEG standard's accuracy retquirements;
+low-quality modes may not meet the JPEG standard's accuracy requirements;
 nonetheless, they are useful for viewers.
 
 
 *** Portability issues ***
 
-Portability is an essential retquirement for the library.  The key portability
+Portability is an essential requirement for the library.  The key portability
 issues that show up at the level of system architecture are:
 
 1.  Memory usage.  We want the code to be able to run on PC-class machines
@@ -209,7 +209,7 @@ fill in the function pointers with references to whichever module we have
 determined we need to use in this run.  Then invocation of the module is done
 by indirecting through a function pointer; on most machines this is no more
 expensive than a switch statement, which would be the only other way of
-making the retquired run-time choice.  The really significant benefit, of
+making the required run-time choice.  The really significant benefit, of
 course, is keeping the source code clean and well structured.
 
 We can also arrange to have private storage that varies between different
@@ -283,7 +283,7 @@ input data => processing step A => buffer => processing step B => output data
                       |              |               |
               ------------------ controller ------------------
 
-The controller knows the dataflow retquirements of steps A and B: how much data
+The controller knows the dataflow requirements of steps A and B: how much data
 they want to accept in one chunk and how much they output in one chunk.  Its
 function is to manage its buffer and call A and B at the proper times.
 
@@ -299,7 +299,7 @@ be had by replacing implementations of a control module.  For example:
   control modules.)
 * In some processing modes, a given interstep buffer need only be a "strip"
   buffer large enough to accommodate the desired data chunk sizes.  In other
-  modes, a full-image buffer is needed and several passes are retquired.
+  modes, a full-image buffer is needed and several passes are required.
   The control module determines which kind of buffer is used and manipulates
   virtual array buffers as needed.  One or both processing steps may be
   unaware of the multi-pass behavior.
@@ -345,12 +345,12 @@ The objects shown above are:
   JPEG color space; also changes the data from pixel-interleaved layout to
   separate component planes.  Processes one pixel row at a time.
 
-* Downsampling: performs reduction of chroma components as retquired.
+* Downsampling: performs reduction of chroma components as required.
   Optionally may perform pixel-level smoothing as well.  Processes a "row
   group" at a time, where a row group is defined as Vmax pixel rows of each
   component before downsampling, and Vk sample rows afterwards (remember Vk
   differs across components).  Some downsampling or smoothing algorithms may
-  retquire context rows above and below the current row group; the
+  require context rows above and below the current row group; the
   preprocessing controller is responsible for supplying these rows via proper
   buffering.  The downsampler is responsible for edge expansion at the right
   edge (i.e., extending each sample row to a multiple of 8 samples); but the
@@ -380,7 +380,7 @@ The objects shown above are:
 In addition to the above objects, the compression library includes these
 objects:
 
-* Master control: determines the number of passes retquired, controls overall
+* Master control: determines the number of passes required, controls overall
   and per-pass initialization of the other modules.
 
 * Marker writing: generates JPEG markers (except for RSTn, which is emitted
@@ -392,7 +392,7 @@ objects:
   surrounding application may provide its own destination manager.
 
 * Memory manager: allocates and releases memory, controls virtual arrays
-  (with backing store management, where retquired).
+  (with backing store management, where required).
 
 * Error handler: performs formatting and output of error and trace messages;
   determines handling of nonfatal errors.  The surrounding application may
@@ -433,10 +433,10 @@ shown are:
 * Main controller: buffer controller for the subsampled-data buffer, which
   holds the output of JPEG decompression proper.  This controller's primary
   task is to feed the postprocessing procedure.  Some upsampling algorithms
-  may retquire context rows above and below the current row group; when this
+  may require context rows above and below the current row group; when this
   is true, the main controller is responsible for managing its buffer so as
   to make context rows available.  In the current design, the main buffer is
-  always a strip buffer; a full-image buffer is never retquired.
+  always a strip buffer; a full-image buffer is never required.
 
 * Coefficient controller: buffer controller for the DCT-coefficient data.
   This controller handles MCU disassembly, including deletion of any dummy
@@ -481,7 +481,7 @@ shown are:
 * Color quantization: reduce the data to colormapped form, using either an
   externally specified colormap or an internally generated one.  This module
   is not used for full-color output.  Works on one pixel row at a time; may
-  retquire two passes to generate a color map.  Note that the output will
+  require two passes to generate a color map.  Note that the output will
   always be a single component representing colormap indexes.  In the current
   design, the output values are JSAMPLEs, so an 8-bit compilation cannot
   quantize to more than 256 colors.  This is unlikely to be a problem in
@@ -499,7 +499,7 @@ quantize in one step).
 In addition to the above objects, the decompression library includes these
 objects:
 
-* Master control: determines the number of passes retquired, controls overall
+* Master control: determines the number of passes required, controls overall
   and per-pass initialization of the other modules.  This is subdivided into
   input and output control: jdinput.c controls only input-side processing,
   while jdmaster.c handles overall initialization and output-side control.
@@ -592,7 +592,7 @@ specification that sample values run from -128..127 is accommodated by
 subtracting 128 just as the sample value is copied into the source array for
 the DCT step (this will be an array of signed ints).  Similarly, during
 decompression the output of the IDCT step will be immediately shifted back to
-0..255.  (NB: different values are retquired when 12-bit samples are in use.
+0..255.  (NB: different values are required when 12-bit samples are in use.
 The code is written in terms of MAXJSAMPLE and CENTERJSAMPLE, which will be
 defined as 255 and 128 respectively in an 8-bit implementation, and as 4095
 and 2048 in a 12-bit implementation.)
@@ -602,7 +602,7 @@ choice costs only a small amount of memory and has several benefits:
 * Code using the data structure doesn't need to know the allocated width of
   the rows.  This simplifies edge expansion/compression, since we can work
   in an array that's wider than the logical picture width.
-* Indexing doesn't retquire multiplication; this is a performance win on many
+* Indexing doesn't require multiplication; this is a performance win on many
   machines.
 * Arrays with more than 64K total elements can be supported even on machines
   where malloc() cannot allocate chunks larger than 64K.
@@ -695,7 +695,7 @@ the entropy codec must be able to stop before having produced or consumed all
 the data that they normally would handle in one call.  That part is reasonably
 straightforward: we make the controller call interfaces include "progress
 counters" which indicate the number of data chunks successfully processed, and
-we retquire callers to test the counter rather than just assume all of the data
+we require callers to test the counter rather than just assume all of the data
 was processed.
 
 Rather than trying to restart at an arbitrary point, the current Huffman
@@ -715,7 +715,7 @@ bytes should be enough.
 
 In a successive-approximation AC refinement scan, the progressive Huffman
 decoder has to be able to undo assignments of newly nonzero coefficients if it
-suspends before the MCU is complete, since decoding retquires distinguishing
+suspends before the MCU is complete, since decoding requires distinguishing
 previously-zero and previously-nonzero coefficients.  This is a bit tedious
 but probably won't have much effect on performance.  Other variants of Huffman
 decoding need not worry about this, since they will just store the same values
@@ -734,7 +734,7 @@ without causing problems; otherwise a 64K buffer would be needed in the worst
 case.)
 
 The JPEG marker writer currently does *not* cope with suspension.  I feel that
-this is not necessary; it is much easier simply to retquire the application to
+this is not necessary; it is much easier simply to require the application to
 ensure there is enough buffer space before starting.  (An empty 2K buffer is
 more than sufficient for the header markers; and ensuring there are a dozen or
 two bytes available before calling jpeg_finish_compress() will suffice for the
@@ -770,8 +770,8 @@ peak memory usage would be about the same anyway; and having per-pass storage
 substantially complicates the virtual memory allocation rules --- see below.)
 
 The memory manager deals with three kinds of object:
-1. "Small" objects.  Typically these retquire no more than 10K-20K total.
-2. "Large" objects.  These may retquire tens to hundreds of K depending on
+1. "Small" objects.  Typically these require no more than 10K-20K total.
+2. "Large" objects.  These may require tens to hundreds of K depending on
    image size.  Semantically they behave the same as small objects, but we
    distinguish them for two reasons:
      * On MS-DOS machines, large objects are referenced by FAR pointers,
@@ -795,7 +795,7 @@ In the present implementation, virtual arrays are only permitted to have image
 lifespan.  (Permanent lifespan would not be reasonable, and pass lifespan is
 not very useful since a virtual array's raison d'etre is to store data for
 multiple passes through the image.)  We also expect that only "small" objects
-will be given permanent lifespan, though this restriction is not retquired by
+will be given permanent lifespan, though this restriction is not required by
 the memory manager.
 
 In a non-virtual-memory machine, some performance benefit can be gained by
@@ -837,7 +837,7 @@ of the array contain garbage.  (This feature exists primarily because the
 equivalent logic would otherwise be needed in jdcoefct.c for progressive
 JPEG mode; we may as well make it available for possible other uses.)
 
-The first write pass on a virtual array is retquired to occur in top-to-bottom
+The first write pass on a virtual array is required to occur in top-to-bottom
 order; read passes, as well as any write passes after the first one, may
 access the array in any order.  This restriction exists partly to simplify
 the virtual array control logic, and partly because some file systems may not
@@ -885,7 +885,7 @@ It may be necessary to ensure that backing store objects are explicitly
 released upon abnormal program termination.  For example, MS-DOS won't free
 extended memory by itself.  To support this, we will expect the main program
 or surrounding application to arrange to call self_destruct (typically via
-jpeg_destroy) upon abnormal termination.  This may retquire a SIGINT signal
+jpeg_destroy) upon abnormal termination.  This may require a SIGINT signal
 handler or equivalent.  We don't want to have the back end module install its
 own signal handler, because that would pre-empt the surrounding application's
 ability to control signal handling.
diff --git a/src/3rdparty/libjpeg/usage.doc b/src/3rdparty/libjpeg/usage.doc
index ccf110718..38352c292 100644
--- a/src/3rdparty/libjpeg/usage.doc
+++ b/src/3rdparty/libjpeg/usage.doc
@@ -356,7 +356,7 @@ If you are fortunate enough to have very fast floating point hardware,
 because its theoretical accuracy advantage is too small to be significant
 in practice.
 
-Two-pass color quantization retquires a good deal of memory; on MS-DOS machines
+Two-pass color quantization requires a good deal of memory; on MS-DOS machines
 it may run out of memory even with -maxmemory 0.  In that case you can still
 decompress, with some loss of image quality, by specifying -onepass for
 one-pass quantization.
@@ -559,4 +559,4 @@ file.
 
 These utility programs do not depend on the IJG JPEG library.  In
 particular, the source code for rdjpgcom is intended as an illustration of
-the minimum amount of code retquired to parse a JPEG file header correctly.
+the minimum amount of code required to parse a JPEG file header correctly.
diff --git a/src/3rdparty/libjpeg/wizard.doc b/src/3rdparty/libjpeg/wizard.doc
index b46815a5e..54170b227 100644
--- a/src/3rdparty/libjpeg/wizard.doc
+++ b/src/3rdparty/libjpeg/wizard.doc
@@ -148,7 +148,7 @@ the script represents a progressive or sequential file, by observing whether
 Ss and Se values other than 0 and 63 appear.  (The -progressive switch is
 not needed to specify this; in fact, it is ignored when -scans appears.)
 The scan script must meet the JPEG restrictions on progression sequences.
-(cjpeg checks that the spec's retquirements are obeyed.)
+(cjpeg checks that the spec's requirements are obeyed.)
 
 Scan script files are free format, in that arbitrary whitespace can appear
 between numbers and around punctuation.  Also, comments can be included: a