Play your MPG file. In a browser that cannot.
safe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQsafe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQ
No browser plays MPEG‑1 or MPEG‑2 video. Chrome, Safari and Firefox
decode H.264, VP8, VP9 and AV1; not one of them has ever shipped an MPEG‑1
decoder for <video>. Point any of them at an .mpg
and you get a black rectangle, which is why "how do I play an MPG file" is still
a question thirty years after the format was standardised.
This tab answers it without installing anything. Drop the file, drag the scrubber to a moment, and press play: OmniViewer cuts a few seconds out of the stream at a pack boundary, decodes them into H.264 with a real FFmpeg build compiled to WebAssembly, and hands the browser a format it understands. The decode happens in the tab — there is no upload, no server and no plug-in.
Because it seeks by the pack clock rather than by reading forward, the file’s size does not matter. Scrubbing to minute forty of a multi-gigabyte capture reads a few megabytes around minute forty and nothing else.
It’s one lens on OmniViewer’s MPG Viewer & Converter — MP4, MOV, GIF: drop a file and every tab is one click away. OmniViewer opens every file format, entirely in your browser — no upload, no server.
No. OmniViewer is a static page with no server-side processing. Your .mpg is read directly by your browser, and the decoding and converting run inside the tab in WebAssembly. Nothing is transmitted, nothing is stored and there is no account.
Because no browser ships an MPEG-1 or MPEG-2 video decoder for the <video> element. They decode H.264, VP8, VP9 and AV1 instead. The format is thirty years old and its patents expired, but the decoder was never added, so an .mpg in a browser is a black rectangle. OmniViewer works around it by decoding a few seconds of the stream into H.264 locally and playing that.
A flat run of packs. Each pack starts with the four bytes 00 00 01 BA, carries a clock value called the system clock reference, and is followed by PES packets holding the coded video and audio. There is no index anywhere in the file — no moov box, no seek table, no directory. The container is the sequence of packs and nothing else.
Yes, and to MOV, WebM, animated GIF, MP3, WAV or a single PNG frame. Open the CONVERT tab, set the start and length, choose a width and a quality, and press the button on the format you want. The encode runs in your browser on a real FFmpeg build compiled to WebAssembly, so there is no upload, no queue and no watermark.
There is no cap on opening one. The parse reads a bounded two-megabyte prefix whatever the file size, and the raw and hex views read only the bytes on screen. Converting is bounded differently: the encoder is handed a pack-aligned window around the clip you asked for, typically a few megabytes, so converting a clip out of a twenty-gigabyte capture costs about what converting one out of a small file costs.
Through the pack clock. Every pack header carries a system clock reference, so a byte offset for a given moment can be interpolated, probed with one small read, corrected from the clock value actually found there, and re-aimed — four probes at most. The cut is then moved back to the pack that carries the next sequence header, so the window decodes cleanly from its first frame.
Somewhat, and the tab says so on every card. MPEG-1 and MPEG-2 are already lossy, so re-encoding to H.264 or VP8 is a second lossy pass. At the High quality setting the difference is not visible at normal viewing distance. WAV is the exception — it is uncompressed, so extracting audio to WAV adds no further loss at all.
A .mpg or .mpeg is a program stream: video and audio multiplexed together in packs. A .m1v or .m2v is a bare video elementary stream — coded frames with no packs, no PES packets and no audio at all. A .vob is a DVD Video Object, which is a program stream that also carries AC-3, DTS or LPCM audio and subtitle subpictures in its private streams. All of them open here.
It shows the compression strategy. I-frames are complete pictures and stand alone, P-frames reference what came before, and B-frames reference both directions. A stream that is mostly B-frames is compressing hard; one that is mostly I-frames is either very short on GOP length or was made for editing. It also explains seeking: a decoder can only start at an I-frame, which is why scrubbing lands where it does.
Not yet. A transport stream carries the same video and audio but frames it in fixed 188-byte packets addressed by PID, with tables mapping the programs — a different walk rather than a bigger one. It is listed as planned on the feature map.