Create conversion doc page, small fixes

docs/.vitepress/config.mts

@@ -21,21 +21,27 @@ export default withMermaid({
 				],
 			},
 			{
-				text: 'Reading media files',
+				text: 'Reading',
 				items: [
-					{ text: 'Reading overview', link: '/guide/reading-overview' },
+					{ text: 'Reading media files', link: '/guide/reading-media-files' },
 					{ text: 'Media sinks', link: '/guide/media-sinks' },
 					{ text: 'Input formats', link: '/guide/input-formats' },
 				],
 			},
 			{
-				text: 'Writing media files',
+				text: 'Writing',
 				items: [
-					{ text: 'Writing overview', link: '/guide/writing-overview' },
+					{ text: 'Writing media files', link: '/guide/writing-media-files' },
 					{ text: 'Media sources', link: '/guide/media-sources' },
 					{ text: 'Output formats', link: '/guide/output-formats' },
 				],
 			},
+			{
+				text: 'Conversion',
+				items: [
+					{ text: 'Converting media files', link: '/guide/converting-media-files' },
+				],
+			},
 			{
 				text: 'Miscellaneous',
 				items: [

docs/guide/converting-media-files.md

@@ -0,0 +1,3 @@
+# Converting media files
+
+ayo

docs/guide/input-formats.md

@@ -1,7 +1,7 @@
 # Input formats
 
 Mediakit supports a wide variety of commonly used container formats for reading input files. These *input formats* are used in two ways:
-- When creating an `Input`, they are used to specify the list of supported container formats. See [Creating a new input](./reading-overview#creating-a-new-input) for more.
+- When creating an `Input`, they are used to specify the list of supported container formats. See [Creating a new input](./reading-media-files#creating-a-new-input) for more.
 - Given an existing `Input`, its `getFormat` method returns the *actual* format of the file as an `InputFormat`.
 
 ## Input format properties
@@ -16,7 +16,7 @@ You can also retrieve the format's base MIME type:
 inputFormat.mimeType; // => 'video/mp4'
 ```
 
-If you want a file's full MIME type, which depends on track codecs, use [`getMimeType`](./reading-overview#reading-file-metadata) on `Input` instead.
+If you want a file's full MIME type, which depends on track codecs, use [`getMimeType`](./reading-media-files#reading-file-metadata) on `Input` instead.
 
 ## Input format singletons
 

docs/guide/media-sinks.md

@@ -4,7 +4,7 @@
 
 *Media sinks* offer ways to extract media data from an `InputTrack`. Different media sinks provide different levels of abstraction and cater to different use cases.
 
-For information on how to obtain input tracks, or how to generally read data from media files, refer to the [Reading overview](./reading-overview).
+For information on how to obtain input tracks, or how to generally read data from media files, refer to [Reading media files](./reading-media-files).
 
 ### General usage
 

docs/guide/media-sources.md

@@ -8,7 +8,7 @@ Media sources are not to be confused with [MediaSource](https://developer.mozill
 
 _Media sources_ provide APIs for adding media data to an output file. Different media sources provide different levels of abstraction and cater to different use cases.
 
-For information on how to use media sources to create output tracks, check the [writing overview](./writing-overview).
+For information on how to use media sources to create output tracks, check [Writing media files](./writing-media-files).
 
 Most media sources follow this code pattern to add media data:
 ```ts
@@ -21,11 +21,11 @@ When you're done using the source, meaning no additional media data will be adde
 ```ts
 mediaSource.close();
 ```
-Closing sources manually is _technically_ not required and will happen automatically when finalizing the `Output`. However, if your `Output` has multiple tracks and not all of them finish supplying their data at the same time (for example, adding all audio first and then all video), closing sources early will improve performance and lower memory usage. This is because the `Output` can better "plan ahead", knowing it doesn't have to wait for certain tracks anymore (see [Packet buffering](./writing-overview#packet-buffering)). Therefore, it is good practice to always manually close all media sources as soon as you are done using them.
+Closing sources manually is _technically_ not required and will happen automatically when finalizing the `Output`. However, if your `Output` has multiple tracks and not all of them finish supplying their data at the same time (for example, adding all audio first and then all video), closing sources early will improve performance and lower memory usage. This is because the `Output` can better "plan ahead", knowing it doesn't have to wait for certain tracks anymore (see [Packet buffering](./writing-media-files#packet-buffering)). Therefore, it is good practice to always manually close all media sources as soon as you are done using them.
 
 ### Backpressure
 
-Media sources are the means by which backpressure is propagated from the output pipeline into your application logic. The `Output` may want to apply backpressure if the encoders or the [StreamTarget](./writing-overview#streamtarget)'s writable can't keep up.
+Media sources are the means by which backpressure is propagated from the output pipeline into your application logic. The `Output` may want to apply backpressure if the encoders or the [StreamTarget](./writing-media-files#streamtarget)'s writable can't keep up.
 
 Backpressure is communicated by media sources via promises. All media sources with an `add` method return a promise:
 ```ts

docs/guide/output-formats.md

@@ -80,10 +80,10 @@ type IsobmffOutputFormatOptions = {
 		This option ensures append-only writing.
 		:::
 		::: warning
-		This option requires [packet buffering](./writing-overview#packet-buffering).
+		This option requires [packet buffering](./writing-media-files#packet-buffering).
 		:::
 	- `undefined`\
-		The default option; it behaves like `'in-memory'` when using [`BufferTarget`](./writing-overview#buffertarget) and like `false` otherwise.
+		The default option; it behaves like `'in-memory'` when using [`BufferTarget`](./writing-media-files#buffertarget) and like `false` otherwise.
 - `minimumFragmentDuration`\
 	Only relevant when `fastStart` is `'fragmented'`. Sets the minimum duration in seconds a fragment must have to be finalized and written to the file. Defaults to 1 second.
 - `onFtyp`\

docs/guide/reading-media-files.md

@@ -1,4 +1,4 @@
-# Reading overview
+# Reading media files
 
 Mediakit allows you to read media files with great control and efficiency. You can use it to extract metadata (such as duration or resolution), as well as to read actual media data from video and audio tracks with frame-accurate timing. Many commonly used [input file formats](./input-formats) are supported. Using [input sources](#input-sources), data can be read from multiple sources, such as directly from memory, from the user's disk, or even over the network.
 

docs/guide/supported-formats-and-codecs.md

@@ -179,7 +179,7 @@ Codec encodability checks take [custom encoders](#custom-encoders) into account.
 
 ## Querying codec decodability
 
-Whether a codec can be decoded depends on the specific codec configuration of an `InputTrack`; you can use its [`canDecode`](./reading-overview#codec-information) method to check.
+Whether a codec can be decoded depends on the specific codec configuration of an `InputTrack`; you can use its [`canDecode`](./reading-media-files#codec-information) method to check.
 
 ## Custom coders
 

docs/guide/writing-media-files.md

@@ -1,4 +1,4 @@
-# Writing overview
+# Writing media files
 
 Mediakit enables you to create media files with very fine levels of control. You can add an arbitrary number of video, audio and subtitle tracks to a media file, and precisely control the timing of media data. This library supports [many output file formats](./output-formats). Using [output targets](#output-targets), you can decide if you want to build up the entire file in memory or stream it out in chunks as it's being created - allowing you to create very large files.