v0.8.0

Media Analyzer

• Captions panel: CEA-608 (CC1–CC4 and XDS) and CEA-708 as text, each command shown with its parameters
• Faster on large files in the browser, roughly a fifth off the time
• The analyzer detects more file formats
• Better stream identification in transport streams
• MCP server: added list_caption_tracks and read_captions
• Fixed a bug that could change the site language during a visit

YUV viewer

• Raw YUV detection rebuilt from the file's structure
• YV12 is its own format, not folded into I420
• Fixed flat green frames when a plane row is not a multiple of 4

More detail on each, below.

Captions get a surface built for text

Closed captions never fitted the packet paradigm. They arrive as two-byte pairs scattered across video SEI messages, MPEG-2 user_data and SMPTE 2038 VANC, each pair meaningless on its own. A caption is a run of text assembled from dozens of them, so a packet list could only ever show you the bytes and never the sentence. Until now the analyzer did exactly that: opaque byte pairs on whatever packet happened to carry them.

Captions are now lifted out of the carrying stream into caption streams of their own, decoded into CEA-608 and CEA-708 tracks, and presented in a dedicated Captions panel as lines of text. CEA-608 covers channels CC1–CC4 and XDS; CEA-708 covers the DTVCC services. Control commands are named with their parameters decoded rather than shown as raw control pairs, and you can hide them behind a checkbox when you want to read the text alone. XDS packets are assembled across their control pairs and reported by what each class and type carries, Content Advisory ratings included.

The part worth dwelling on is that the new view never loses what the old one showed. Every caption character is mapped to both of its positions, stepping over emulation prevention bytes where they intrude, so a run of text opens to the bytes it was read from in the hex view, and a packet offers Show in Captions to jump to the captions that cross it. Captions are put in display order, data repeated within a picture is dropped, accented and extended characters are decoded, and pairs that fail odd parity are reported rather than silently accepted.

For agents, the MCP server gained list_caption_tracks and read_captions, so an AI agent can read a file's captions as text, useful for "does this stream actually carry the captions the spec claims?" without a human watching a player.

Raw YUV files identify themselves

Raw YUV carries no header, so opening one means telling the viewer its dimensions and pixel layout, and the old quick scan was poor at guessing them. It only tried a fixed set of sizes, so plenty of common geometries were never candidates, and it presented its guesses as if they were certain.

It has been replaced by a detector that treats the problem as hypothesis testing over storage layouts. It reads the byte ranges it needs, measures row-stride and plane-layout evidence on them, and returns ranked hypotheses with a calibrated confidence. Across our test corpus it gets the geometry right in the large majority of cases where the old scan got it wrong.

The more useful change is what it does when it cannot be sure. Some files genuinely cannot be resolved from their bytes. The 4:2:0 family is indistinguishable when the chroma planes carry no picture, and the detector now says so, listing the layouts it could not separate so the file dialog can offer them as alternatives instead of picking one and sounding certain. How well any detector scores depends heavily on what is in the test set, so the claim we will stand behind is the narrower one: it is right far more often than what it replaces, and when it is unsure it tells you.

Two YUV viewer fixes came along with it. YV12 is now its own format, listed in the format menu and the pixel inspector, with its planes sliced V-then-U, rather than being quietly treated as I420 with the chroma planes swapped. And the decoder's pixel unpack alignment is set correctly, which fixes the flat green frames you would get at widths like 1916 or 1350, where a plane row is not a multiple of four bytes.

A file we cannot parse now tells you what it is

If no parser recognized a file, the scan ended with "stream is broken or unrecognized", even for a playlist saved under a video name, a PNG, a ZIP, a PDF, or the HTML a download returned.

The engine now names it from its opening bytes. A streaming manifest points at the media you want, something that is not media is called out as such, and media we do not parse yet is named. The file stays open, the message says which, and the hex view still shows the bytes. A file of one repeated byte is reported as holding no recognizable data, and the byte is named.

Faster on large files in the browser

In the browser the parser used to wait out each chunk, so a large file paid hundreds of serial round trips into JavaScript.

Chunk loading now overlaps parsing, about a fifth off the time on a large file. Read-ahead follows only sequential progress, so a parser that jumps around does not fetch bytes it will never read. Native use is unaffected.

Everything else

Transport stream identification improved in several ways that are hard to separate from one another but easy to describe: captures that previously came back as entirely unknown are now recognized, a service whose parameter sets arrive late in the file is no longer left as "Unknown Video" while its neighbour is identified, and a private stream type that means one thing on a Blu-ray disc and another in a DVB mux is now read according to what the mux says about it. On the codec side, an AC-4 field layout was corrected.

On the MCP server, get_packet stopped accepting index and file_pos together, the detected-format list is deduplicated with counts instead of a long repetitive array, and logging moved to stderr so a warning can no longer corrupt the JSON-RPC stream on stdout.

On the web side, a bug that could change the site language during a visit is fixed.