Inspect your MPG in hex.
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
Drop an .mpg and OmniViewer shows its exact bytes: offsets,
hexadecimal and a decoded ASCII panel, reading only what is on screen so the file
can be any size. The structure is unusually easy to follow by eye here — look
for 00 00 01 and the byte after it names what follows, so the
BA at the top of every pack marches down the file at regular
intervals.
Hex is where container questions get settled that no player will answer: whether a
file is truncated mid-pack, whether it is a program stream or a bare elementary
stream, or whether something calling itself .mpg is really an MPEG at
all. The same drop also decodes the picture, converts the clip and reports stats.
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.