@@ -130,22 +130,22 @@ the driver state and therefore only adjust the requested rectangle.
Suppose scaling on a video capture device is restricted to a factor 1:1
or 2:1 in either direction and the target image size must be a multiple
-of 16 × 16 pixels. The source cropping rectangle is set to defaults,
-which are also the upper limit in this example, of 640 × 400 pixels at
-offset 0, 0. An application requests an image size of 300 × 225 pixels,
+of 16 x 16 pixels. The source cropping rectangle is set to defaults,
+which are also the upper limit in this example, of 640 x 400 pixels at
+offset 0, 0. An application requests an image size of 300 x 225 pixels,
assuming video will be scaled down from the "full picture" accordingly.
-The driver sets the image size to the closest possible values 304 × 224,
+The driver sets the image size to the closest possible values 304 x 224,
then chooses the cropping rectangle closest to the requested size, that
-is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
+is 608 x 224 (224 x 2:1 would exceed the limit 400). The offset 0, 0 is
still valid, thus unmodified. Given the default cropping rectangle
reported by :ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>` the application can
easily propose another offset to center the cropping rectangle.
Now the application may insist on covering an area using a picture
aspect ratio closer to the original request, so it asks for a cropping
-rectangle of 608 × 456 pixels. The present scaling factors limit
-cropping to 640 × 384, so the driver returns the cropping size 608 × 384
-and adjusts the image size to closest possible 304 × 192.
+rectangle of 608 x 456 pixels. The present scaling factors limit
+cropping to 640 x 384, so the driver returns the cropping size 608 x 384
+and adjusts the image size to closest possible 304 x 192.
Examples
@@ -38,7 +38,7 @@ Conventions and Notations Used in This Document
6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i =
[0..2]: i = 0, 1, 2.
-7. Given an ``OUTPUT`` buffer A, then A’ represents a buffer on the ``CAPTURE``
+7. Given an ``OUTPUT`` buffer A, then A' represents a buffer on the ``CAPTURE``
queue containing data that resulted from processing buffer A.
.. _decoder-glossary:
@@ -288,7 +288,7 @@ Initialization
Changing the ``OUTPUT`` format may change the currently set ``CAPTURE``
format. How the new ``CAPTURE`` format is determined is up to the decoder
- and the client must ensure it matches its needs afterwards.
+ and the client must ensure it matches its needs afterwards.
2. Allocate source (bytestream) buffers via :c:func:`VIDIOC_REQBUFS` on
``OUTPUT``.
@@ -874,7 +874,7 @@ it may be affected as per normal decoder operation.
any of the following results on the ``CAPTURE`` queue is allowed:
- {A’, B’, G’, H’}, {A’, G’, H’}, {G’, H’}.
+ {A', B', G', H'}, {A', G', H'}, {G', H'}.
To determine the CAPTURE buffer containing the first decoded frame after the
seek, the client may observe the timestamps to match the CAPTURE and OUTPUT
@@ -447,7 +447,7 @@ name ``V4L2_FBUF_FLAG_CHROMAKEY``.
In V4L, storing a bitmap pointer in ``clips`` and setting ``clipcount``
to ``VIDEO_CLIP_BITMAP`` (-1) requests bitmap clipping, using a fixed
-size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
+size bitmap of 1024 x 625 bits. Struct :c:type:`v4l2_window`
has a separate ``bitmap`` pointer field for this purpose and the bitmap
size is determined by ``w.width`` and ``w.height``.
@@ -100,7 +100,7 @@ Where ``X`` is a non-negative integer.
$ tree /dev/v4l
/dev/v4l
├── by-id
- │ └── usb-OmniVision._USB_Camera-B4.04.27.1-video-index0 -> ../../video0
+ │ └── usb-OmniVision._USB_Camera-B4.04.27.1-video-index0 -> ../../video0
└── by-path
└── pci-0000:00:14.0-usb-0:2:1.0-video-index0 -> ../../video0
@@ -69,8 +69,8 @@ overlay devices.
* - struct :ref:`v4l2_rect <v4l2-rect-crop>`
- ``defrect``
- Default cropping rectangle, it shall cover the "whole picture".
- Assuming pixel aspect 1/1 this could be for example a 640 × 480
- rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM
+ Assuming pixel aspect 1/1 this could be for example a 640 x 480
+ rectangle for NTSC, a 768 x 576 rectangle for PAL and SECAM
centered over the active picture area. The same co-ordinate system
as for ``bounds`` is used.
* - struct :c:type:`v4l2_fract`
The conversion tools used during DocBook/LaTeX/Markdown->ReST conversion and some automatic rules which exists on certain text editors like LibreOffice turned ASCII characters into some UTF-8 alternatives that are better displayed on html and PDF. While it is OK to use UTF-8 characters in Linux, it is better to use the ASCII subset instead of using an UTF-8 equivalent character as it makes life easier for tools like grep, and are easier to edit with the some commonly used text/source code editors. Also, Sphinx already do such conversion automatically outside literal blocks: https://docutils.sourceforge.io/docs/user/smartquotes.html So, replace the occurences of the following UTF-8 characters: - U+00a0 (' '): NO-BREAK SPACE - U+00d7 ('×'): MULTIPLICATION SIGN - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> --- Documentation/userspace-api/media/v4l/crop.rst | 16 ++++++++-------- .../userspace-api/media/v4l/dev-decoder.rst | 6 +++--- .../userspace-api/media/v4l/diff-v4l.rst | 2 +- Documentation/userspace-api/media/v4l/open.rst | 2 +- .../userspace-api/media/v4l/vidioc-cropcap.rst | 4 ++-- 5 files changed, 15 insertions(+), 15 deletions(-)