Convert MTS to OGV Online for Free
Make an OGV web-video derivative from MTS footage after selecting tracks, choosing Theora/Vorbis settings, and testing actual browser support.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
MTS to OGV Replaces a Camera Transport Stream With Ogg Video
MTS commonly identifies AVCHD camera footage stored as a Blu-ray Disc Audio/Visual and AVCHD form of MPEG-2 Transport Stream. The source can contain AVC/H.264 video, audio services, timestamps, and ancillary material. An OGV file is video in the Ogg container, normally intended for Ogg-compatible video/audio codecs such as Theora and Vorbis. This is not a filename-only conversion: the container, video codec, audio codec, timestamps, and endpoint assumptions change together.
Xiph describes Ogg as a stream-oriented multimedia container that frames and interleaves compressed audio/video, provides error detection, and includes periodic timestamps for seeking. The recommended specific MIME type for a video file is video/ogg. That does not mean every device or browser will accept every Ogg codec combination. Decide why OGV is required—an Ogg/Theora delivery, a legacy web fallback, or a controlled offline receiver—and write the intended codec pair into the job specification.
Keep MTS acquisition material as the source record. An OGV derivative normally omits the original transport-stream organisation, camera folder context, any unselected tracks, and source metadata not deliberately represented. Preserve captions, alternate tracks, rights information, and a conversion manifest outside the video rather than assuming the new web file carries them.
Choose the MTS Video and Audio Services Before Encoding OGV
Inspect source video codec/profile, dimensions, frame rate, scan type, display aspect, duration, and every audio stream's codec, channels, rate, label, and audible role. AVCHD-era MTS often uses AVC/H.264 video, but the actual file rather than its extension is authoritative. Track order is not programme intent. Audition the beginning, a known middle event, and the end for each plausible audio stream before making a Theora/Vorbis output.
Ogg can hold multiple logical bitstreams, but container capability is not a promise that a chosen player offers understandable selection among them. Xiph's Skeleton metadata can describe stream serial number, MIME type, language and other details, yet Xiph also notes that a generic player cannot automatically parse, seek, understand, and dynamically handle every possible multitrack Ogg combination. For ordinary OGV delivery, select the required primary video and audio deliberately and retain other source tracks separately unless the receiver's exact multitrack behavior has been tested.
The resulting OGV cannot preserve camera video as Theora by remuxing: AVC and Theora are distinct video encodings. It must be decoded and lossy re-encoded. The same is true when source audio becomes Vorbis. Set expectations accurately: a high output rate can reduce added damage but cannot restore detail removed by prior camera compression or recreate omitted tracks.
Theora and Vorbis Are Separate Lossy Target Decisions
Theora is a lossy video codec and Vorbis is a lossy audio codec in the Xiph ecosystem; Ogg is the container. Avoid calling “OGV” itself a codec. Choose image size, rate, keyframe behavior, video quality/rate policy, audio quality/rate, channels, and sample rate from the intended endpoint. A smaller web fallback can be appropriate, but it should be named as such rather than compared to an unaltered camera master.
Look for target-specific faults. In video, compare moving foliage, hair, water, text, rapid pans, noise, and gradients, where a second lossy encode can show ringing, blockiness, banding, smearing, or unstable detail. In audio, test dialogue consonants, applause, dense music, reverb tails, and the final decay. If source audio is surround but the web target is stereo, the downmix is a new mix decision; listen for lost dialogue, phase issues, and changes in balance.
MDN cautions that Ogg has not gained the wide support needed to be a good first-choice container and says WebM is usually a better choice, while identifying cases where Ogg can serve older Firefox and Chrome releases that predate WebM. Treat that as a compatibility decision, not an aesthetic judgement. Test the exact browsers, operating systems, and players named by the requirement, and offer an additional fallback only when the delivery scope authorizes it.
Ogg Pages and Granule Positions Affect Seeking and Timing
Ogg's basic delivery unit is a page. Xiph's container overview describes a page header, a packet-length list, and payload data; each page has a 64-bit granule position. The codec maps that position to an absolute timestamp, so Ogg does not impose one fixed clock interpretation on all codecs. For a conversion operator, this means that duration and seeking should be tested in the finished OGV rather than inferred from MTS transport timestamps or a transcode log.
Compare the first intended image/sound, one mid-file visual/audio landmark, and the final tail with the selected source tracks. A fixed offset might result from a chosen trim, audio delay, or preroll behavior. A discrepancy that grows over the duration suggests frame-rate, time-base, or processing trouble. Do not attempt to fix a timing mismatch by increasing the video quality setting.
Perform actual late-file seeks in every required receiver. A file that plays from its start may expose keyframe spacing, index, or endpoint limits once a user seeks. Record the player version and landmark when a failure occurs; that distinguishes an Ogg construction issue from a specific browser's codec support or delivery configuration.
Fields, Aspect Ratio, and Source Context Do Not Transfer by Accident
If MTS footage is interlaced, decide whether the OGV target supports that presentation as required or needs a deinterlaced progressive output. Incorrect field interpretation creates combing, while deinterlacing can reduce vertical detail or make motion look unnatural. State the source scan behavior and conversion policy. Also verify displayed aspect ratio: correct pixels with wrong display signaling can make a widescreen shot appear squeezed.
Ogg's framing and Skeleton options do not automatically reproduce an AVCHD folder relationship, camera clip names, caption sidecars, or every source service. Keep a manifest containing source identifier/checksum, selected tracks, source technical properties, Theora/Vorbis settings, deinterlace or scaling decisions, output duration, MIME declaration, and tested endpoint. It makes a web derivative traceable without inventing metadata from a filename.
MTS Transport Material and OGV Web Delivery Compared
| Check | MTS source | OGV output |
|---|---|---|
| Container | AVCHD/BDAV-related MPEG-2 Transport Stream use. | Ogg pages framing selected logical streams. |
| Typical codecs | Often AVC video plus camera audio. | Usually Theora video and Vorbis audio. |
| Timing | Transport-stream programme timing. | Codec-mapped Ogg granule positions. |
| Loss path | Existing camera compression may be lossy. | New Theora/Vorbis encoding is lossy. |
| Track behavior | Several source services may exist. | Select and test tracks; multitrack support varies. |
| Playback | Camera/AVCHD-oriented compatibility. | Endpoint-specific Ogg/browser compatibility. |
MTS to OGV Questions Before Web Publication
Is OGV merely an Ogg extension?
No. It normally identifies Ogg video, and the actual video/audio codecs plus MIME declaration still need to be specified and tested.
Can H.264 from MTS be copied into a Theora OGV target?
No. Theora output requires video transcoding. A container can be flexible, but a declared Theora target has different coded video.
Why does it work in one browser but not another?
Ogg codec support is endpoint-dependent. Test the named browser/platform combination rather than treating Ogg support as universal.
Why is a late seek inaccurate?
Investigate target keyframe/seek behavior, Ogg page timing, player implementation, and source-to-target duration mapping separately.
What should accompany the OGV?
The MTS source, selected-track record, caption/rights assets, settings and manifest, MIME/codec declaration, and endpoint test result.
Before handoff, inspect codecs independently, compare three source landmarks, test high-motion quality, verify aspect and audio selection, seek late in every required browser, and retain the MTS source with the manifest.
Use a small evidence sheet for the final OGV rather than relying on a “conversion complete” message. It should state source and output durations, selected stream identifiers, source and target dimensions, scan treatment, frame rate, Theora/Vorbis options, output size, and each endpoint used for the checks. If a browser receives the file over HTTP, serve a video-specific Ogg MIME type when the content is video; a generic application/ogg fallback is intended for cases where the content class is not known. Compare how the browser reports the file before and after a seek. This identifies server-type, codec-support, and encoding issues as distinct faults.
Do not treat a successful desktop playback as a mobile, TV, or web-service acceptance test. Browser support changes by codec and operating-system media stack. Where OGV exists for a defined legacy audience, establish the actual versions and keep a more broadly supported authorized alternative separately if the publishing requirement permits one. A well-documented limitation is more useful than presenting OGV as a universal video substitute.
Keep the requested OGV codecs explicit in HTML delivery too. A page that advertises video/ogg can still fail when the encoded Theora/Vorbis combination is unsupported by the endpoint. Inspect the actual media rather than using the extension as a codec declaration.