Update doxygen.h

Summary: Remove some unneeded HTML tags and harmonize some the wording with the Documentation files in `website/docs/Overview.md`.

Reviewed By: georges-berenger

Differential Revision: D57986451

fbshipit-source-id: 0289444b5a463a8ee9238be9636515af240207c2

vrs/doxygen.h

@@ -24,42 +24,42 @@
 
 <h2>Overview</h2>
 
-<i><span>TL;DR; VRS is a file format optimized to record &amp; playback streams of sensor data,
+<p><em>TL;DR: VRS is a file format optimized to record &amp; playback streams of sensor data,
  such as images, audio samples, and any other discrete sensors (IMU, temperature, etc), stored
- in per-device streams of timestamped records.</span></i><br/><br/>
+ in per-device streams of timestamped records.</em></p>
 
-<span>If your data is not spread over time, with some kind of "packets" coming from one or
+<p>If your data is not spread over time, with some kind of "packets" coming from one or
 multiple sources, with some level of format regularity, like camera frames, successive samples
 coming from sensors, or timestamps don't make sense for your use case, then VRS is probably
-</span><i><span>not</span></i><span> for you.</span><br/>
+<em>not</em> for you.</p>
 
 <h2>The VRS File Format in Short</h2>
 
 <div><ul>
 
 <li>VRS files contain multiple streams of time-sorted records generated by a set of "devices",
-  typically one per stream.<br/></li>
+  typically one per stream.</li>
 <li>File and streams contain a set of "tags", which are a set of string name-value pairs, to
-  describe them.<br/></li>
+  describe them.</li>
 <li>Streams may contain <code>Configuration</code>, <code>State</code> and <code>Data</code>
   records, each with a timestamp in a common time domain for the whole file.<br>Typically,
-  streams contain with one <code>Configuration</code> and one <code>State</code> record,
-  followed one to millions of <code>Data</code> records.<br/></li>
+  streams contain one <code>Configuration</code> and one <code>State</code> record
+  followed by one to millions of <code>Data</code> records.</li>
 <li>Records are structured as a succession of typed content blocks.<br>Typical content blocks
-  are metadata, image, audio and custom content blocks.<br/></li>
+  are metadata, image, audio and custom content blocks.</li>
 <li>Metadata content blocks contain raw sensor data described once per stream, making the file
   format very efficient. The marginal cost of adding 1 byte of data to each metadata content
-  block of a stream is 1 byte per record (or less, when lossless compression happens).<br/></li>
+  block of a stream is 1 byte per record (or less, when lossless compression happens).</li>
 <li>Records can be losslessly compressed using lz4 or zstd, which can be fast enough to do
-  realtime compression while recording.<br/></li>
-<li>Multiple threads can create records concurrently for the same file.<br/></li>
-<li>VRS supports huge file size (tested with multi terabytes use cases).<br/></li>
+  realtime compression while recording.</li>
+<li>Multiple threads can create records concurrently for the same file.</li>
+<li>VRS supports huge file size (tested with multi terabytes use cases).</li>
 <li>VRS supports chunked files: auto-chunking on creation, automated chunk detection for playback.
-  <br/></li>
-<li>Playback is optimized for timestamp order (key for network streaming).<br/></li>
-<li>Random-access playback is fully supported (in memory file and stream indexes).<br/></li>
+  </li>
+<li>Playback is optimized for timestamp order (key for network streaming).</li>
+<li>Random-access playback is fully supported (in memory file and stream indexes).</li>
 <li>Customizable <code>FileHandler</code> support, to implement streaming from cloud storage
-  (not provided yet).<br/></li>
+  (not provided yet).</li>
 
 </ul></div>