The player showed an ocean, but its duration was Infinity. I had recorded only a few seconds, so that value looked more alarming than the picture did. Before discarding the WebM, I wanted to separate two questions: had the recording lost its video, or was the player unable to report a useful length at that point? The visible waves were already a reason not to treat those questions as interchangeable.
For the test, a short section of an existing waves video was drawn onto a canvas and recorded through MediaRecorder. This was not a webcam recording or a capture of my desktop. Each of three browser engines produced a WebM recording lasting roughly four seconds, with recording chunks collected into the completed file. I then opened those files in different playback engines. I kept the original recordings rather than replacing them with conversions straight away.
I also used ImgIng during this video check, selecting a size-prioritizing MP4 export in its Chinese compression workbench. That separate operation completed and produced a real output file. It was not the duration repair used below. Keeping the results separate matters: a successful conversion in a tool does not tell me what was wrong with an earlier WebM recording, and I did not verify an ImgIng feature that repairs missing duration information.
The left-hand player contains the recording made by Chromium. The right-hand player contains a remuxed copy of that recording. Both were freshly loaded over local HTTP in Chromium 149 for this screenshot, and the displayed values were read after loadeddata: Infinity on the left, 3.912 seconds on the right. Both pictures contain actual decoded waves. This is a controlled playback page, not the product interface, and the screenshot does not measure how accurately either player seeks.
The file inspection gave the comparison something firmer than a changed readout. The original Chromium recording had no Duration element in its Info section and no Cues. The remuxed file had both. Remuxing here meant copying the existing encoded media packets into a new container layout with FFmpeg, rather than encoding the pictures again. The encoded-packet hashes matched before and after. I did not need to claim improved picture quality to explain the changed duration display.
Changing the playback engine also changed the answer. For this same original Chromium recording, Firefox reported 3.464 seconds and WebKit reported 3.950 seconds at the measured loading point, while Chromium reported Infinity. After remuxing, all three reported 3.912 seconds. Other recordings in the small test behaved differently again: one raw recording appeared only 1.093 seconds long in Firefox, and a request to seek to three seconds was clamped to that shorter position. A displayed length can therefore affect what the player lets me do without proving the video packets have disappeared.
I am keeping the claim narrow. Each recording and playback combination was tested once in the main comparison. The English screenshot was a later reload of an existing pair, not another set of recordings. The engines were Chromium 149, Firefox 151, and WebKit 26.5, with WebKit being a test build rather than released Safari. This does not show that remuxing repairs every WebM, nor does a finite duration prove that every target frame can now be reached correctly.
The footage is a shortened, resized recording derived from Alexander Grebenkov’s Ocean waves at Lækjavik beach, Iceland, used under CC BY 3.0. I did not shoot it. If I hit this symptom in another tool, I would first save the original, check whether it contains visible video, and compare the reported duration in another player. Then I would try a remuxed copy and test duration and seeking separately. Infinity is a useful clue here, not a verdict that the recording is empty.
Top comments (0)