[fidldoc] Update reference docs
diff --git a/sdk/fidl/fuchsia.media/README.md b/sdk/fidl/fuchsia.media/README.md
index c1c119a..ee104f5 100644
--- a/sdk/fidl/fuchsia.media/README.md
+++ b/sdk/fidl/fuchsia.media/README.md
@@ -177,7 +177,7 @@
CreateAudioCapturer method, which may be used by clients to capture audio
from either the current default audio input device, or the current default
audio output device depending on the flags passed during creation.</p>
-<p>** Format support **</p>
+<p><strong>Format support</strong></p>
<p>See (Get|Set)StreamType below. By default, the captured stream type will be
initially determined by the currently configured stream type of the source
that the AudioCapturer was bound to at creation time. Users may either fetch
@@ -186,7 +186,7 @@
Note: the stream type may only be set while the system is not running,
meaning that there are no pending capture regions (specified using CaptureAt)
and that the system is not currently running in 'async' capture mode.</p>
-<p>** Buffers and memory management **</p>
+<p><strong>Buffers and memory management</strong></p>
<p>Audio data is captured into a shared memory buffer (a VMO) supplied by the
user to the AudioCapturer during the AddPayloadBuffer call. Please note the
following requirements related to the management of the payload buffer.</p>
@@ -207,11 +207,11 @@
writable, mappable and transferable.</li>
<li>Users should always treat the payload buffer as read-only.</li>
</ul>
-<p>** Synchronous vs. Asynchronous capture mode **</p>
+<p><strong>Synchronous vs. Asynchronous capture mode</strong></p>
<p>The AudioCapturer interface can be used in one of two mutually exclusive
modes: Synchronous and Asynchronous. A description of each mode and their
tradeoffs is given below.</p>
-<p>** Synchronous mode **</p>
+<p><strong>Synchronous mode</strong></p>
<p>By default, AudioCapturer instances are running in 'sync' mode. They will
only capture data when a user supplies at least one region to capture into
using the CaptureAt method. Regions supplied in this way will be filled in
@@ -233,7 +233,7 @@
overwrite any region of the payload buffer after a completed region is
returned, it may overwrite the unfilled portions of a partially filled
buffer which has been returned as a result of a DiscardAllPackets operation.</p>
-<p>** Asynchronous mode **</p>
+<p><strong>Asynchronous mode</strong></p>
<p>While running in 'async' mode, clients do not need to explicitly supply
shared buffer regions to be filled by the AudioCapturer instance. Instead, a
client enters into 'async' mode by calling StartAsyncCapture and supplying a
@@ -259,7 +259,7 @@
<li>To attempt any operation except for SetGain while in the process of
stopping.</li>
</ul>
-<p>** Synchronizing with a StopAsyncCapture operation **</p>
+<p><strong>Synchronizing with a StopAsyncCapture operation</strong></p>
<p>Stopping asynchronous capture mode and returning to synchronous capture mode
is an operation which takes time. Aside from SetGain, users may not call any
other methods on the AudioCapturer interface after calling StopAsyncCapture
@@ -282,7 +282,7 @@
in order to deliver a packet with the end-of-stream flag set on it. Once
users have seen the end-of-stream flag after calling stop, the AudioCapturer
has finished the stop operation and returned to synchronous operating mode.</p>
-<p>** Timing and Overflows **</p>
+<p><strong>Timing and Overflows</strong></p>
<p>All media packets produced by an AudioCapturer instance will have their PTS
field filled out with the capture time of the audio expressed as a timestamp
given by the reference clock timeline. Note: this timestamp is actually a
@@ -332,7 +332,7 @@
In practice, however, if it does, the next produced packet will be flagged
as being discontinuous.</li>
</ol>
-<p>** Synchronous vs. Asynchronous Trade-offs **</p>
+<p><strong>Synchronous vs. Asynchronous Trade-offs</strong></p>
<p>The choice of operating in synchronous vs. asynchronous mode is up to the
user, and depending on the user's requirements, there are some advantages and
disadvantages to each choice.</p>
diff --git a/sdk/fidl/fuchsia.sysmem/README.md b/sdk/fidl/fuchsia.sysmem/README.md
index a46ff07..174a7ac 100644
--- a/sdk/fidl/fuchsia.sysmem/README.md
+++ b/sdk/fidl/fuchsia.sysmem/README.md
@@ -3857,7 +3857,10 @@
<td>
<code>uint32</code>
</td>
- <td></td>
+ <td><p>Stride in bytes of plane 0. Planes beyond plane 0 (if any, depending on
+pixel_format) have a known fixed relationship with plane 0's stride.
+For Intel tiled textures, the stride is for the linearized version of the texture.</p>
+</td>
<td>No default</td>
</tr>
<tr id="ImageFormat_2.display_width">
