A burned-in date or time stamp is the one overlay you cannot borrow pixels for: it sits in every frame, and it changes once a second. On the 640x360 clip measured here the stamp is 168x16 pixels and 1,026 ink pixels, 0.45% of the frame, and inside its own rectangle the picture reads 11.98 dB against a clean copy. A delogo box cleared it in 180 of 180 frames and scored 23.48 dB there, at the cost of rewriting 33.5% of the box. Stacking 89 frames and taking the median, the trick most guides repeat, left 15.4% of the box above 200 luma: the stamp, unchanged.
If the stamp sits in a black bar under the picture, none of that applies. Crop the bar: 40 rows, 992 ink pixels gone, no picture pixel lost, and the surviving frame measured 51.33 dB against clean. The rest of this page is the arithmetic behind those three sentences, and the two places where the numbers look better than the result.
The fixture is 640x360, 30 fps, 6 seconds, 180 frames, encoded once at CRF 20 from a still, grained scene. The stamp is drawn with ffmpeg's drawtext at the bottom right, so its position is known rather than estimated from a screenshot: a bounding box of 168x16 pixels at (460,336), holding 1,026 ink pixels. That is 0.45% of the frame and 38.17% of the box, because a date stamp is mostly gaps between thin strokes.
Small is not the same as harmless. Inside that rectangle the marked file reads 11.98 dB against a clean copy of the same clip, while the whole frame reads 31.31 dB: the mark costs almost nothing to the frame average and destroys the one place it occupies. In the clean file the same box has 0.04% of its pixels at 200 luma or above, so anything brighter than that in the output came from the stamp.
It also changes. The seconds field advances once per second, so all 30 frames inside a second are identical and no two seconds are. That single property is what decides which removal routes can work, and it is why this page is not the logo page with a different noun.
One thing it is not: a tag. ffprobe -show_entries format_tags on the marked file returns major_brand, minor_version, compatible_brands and encoder, and none of them holds the time you see. Rewriting the container with -map_metadata -1 -c copy left the picture identical, PSNR inf, the file at the same 177,255 bytes, and the stamp still on screen. If your date is in a tag rather than in the frames, that is the other problem, and the container page covers it.
The advice is everywhere and it sounds right: a mark that is only sometimes there can be voted out. Per pixel, take the middle value across a window of frames; if the mark is absent from most of them, the middle value is the background, and no interpolation is involved at all. ffmpeg has the filter, tmedian, so this is testable rather than arguable.
| Window | Box PSNR vs clean | Box still at 200+ luma | Time |
|---|---|---|---|
| untouched file | 11.98 dB | 15.40% to 16.03% | — |
| 9 frames (radius 4) | 11.98 dB | 15.44% to 16.03% | 1.62 s |
| 45 frames (radius 22) | 11.98 dB | 15.44% to 16.00% | 4.80 s |
| 89 frames (radius 44) | 12.04 dB | 15.36% to 15.77% | 5.24 s |
Nothing moved. The box score went from 11.98 to 12.04 dB, which is noise, and the share of bright pixels stayed where it started, because the stamp is in 180 of 180 frames. At a stroke pixel, 89 of 89 values are ink, and the median of 89 identical answers is that answer. A longer window cannot fix a majority that never changes.
There is a second cost, visible only when the scene moves. On a version of the same clip where the camera pans 180 pixels, the median left the box where it was, 11.71 to 11.78 dB, and pulled the whole frame down from 31.08 dB to 22.96, 21.22 and 20.32 dB as the window grew, because a median across frames smears anything that moves. So the route that removes nothing is also the route that damages the picture.
To show the filter is not broken, the same stamp was drawn on the first 30 frames only and the clip processed again. A 45-frame window left 136 of 180 frames still carrying ink, because the early windows are majority-stamped. An 89-frame window cleared it completely: 43.84 dB inside the box, 0.04% of the box above 200 luma, which is the clean file's own number.
That is the condition, stated plainly: a temporal median removes a mark that is absent from the majority of the frames in its window. It is a good tool for a preview stamp that stops after ten seconds, a logo that fades in, or a watermark on part of a clip. A date stamp burned in by a camera or a recorder is present in every frame by design, so the condition is never met, and no window length changes that. This is why the advice survives online: it is repeated by people who used it on the case it fits.
A box of 172x20 at (458,334), which is the stamp plus two pixels of margin on each side, produced this against the clean copy:
| Where it is measured | PSNR vs clean |
|---|---|
| inside the stamp box | 23.48 dB |
| outside the box | 53.30 dB |
| whole frame | 41.22 dB |
| frames still holding ink (200+ luma) | 0 of 180 |
The mark is gone in every frame, and the price is visible in the same numbers: 33.5% of the box was rewritten by 20 luma levels or more, with a mean absolute difference of 15.8 against 55.7 for the untouched file. At 640x360 the patch reads as a soft horizontal band in the corner; zoomed 4x it is obvious, because the interpolation produces smooth vertical streaks where the scene had grain. It cost 0.60 s for 180 frames here, and the same filter took 8.19 s on a 6-second 1080p clip when the batch page measured it.
The number that matters most is not in that table. The identical box, on a scene of vertical stripes, scored 73.47 dB and rewrote 0.0% of the box: the stripes are exactly what interpolation from the ring can rebuild. Same filter, same box size, same stamp, 50 dB apart. So "how well does delogo work on a timestamp" has no single answer; it has an answer per background, and the background is the thing you cannot choose. Where the repair is not good enough, the alternatives are the ones on the no-blur page, and they are all worse for a static mark.
Everything above depends on the rectangle being right, and a date stamp makes that harder than a logo does, because the ink is thin and the edges are soft. Shrinking the box by 2 px on each side, to 164x12, produced 14.94 dB and left ink in 180 of 180 frames, between 1.41% and 1.82% of the box above 200 luma. That is roughly a tenth of the original ink, and it is not a faint tint: the surviving edges read as a ghost of the digits, in the same place, on every frame.
Two details explain it. The stamp is drawn with a 1 px black border, which is part of the mark even though it is not bright, and antialiasing puts partial ink one pixel outside the bright strokes. A box measured on the bright pixels alone therefore cuts through the mark. The box used here was 168x16 on the bright pixels, then expanded to 172x20, and the 2 px margin is what made it clean.
The usual escape for a static mark is to take the pixels from another frame, which works when the mark moves relative to the picture. A date stamp does not move, and the scene here does not either, so frame 0 and frame 30 are identical outside the stamp: PSNR inf there. Inside the box they differ, and the score is 20.13 dB.
That looks like an improvement over 11.98 dB, and it is the most misleading number on this page. The pixels being imported are the same rectangle one second earlier, which means the digits are a different time: copy frame 30's box into frame 0 and the clip now claims 09:03:01 at the moment it was 09:03:00. PSNR rewards it because the strokes land in nearly the same places. Nothing in the metric knows what the digits say. The route that does work this way, and only when the mark travels across a moving background, is on the logo page.
Many recordings put the stamp under the picture rather than on it: a letterboxed file, a camera that pads 16:9 into a taller frame, a screen capture with a status strip. In that case the cheapest correct answer is to delete the rows, because there is no picture in them. Measured on a 640x400 frame with a 40-row bar: the bar is 10.00% of the frame height, the stamp inside it is 167x13 and 992 ink pixels, and those 992 pixels are the only non-black pixels in the bar.
Cropping the 40 rows returned a 640x360 frame that measured 51.33 dB against the clean picture, which is the cost of the re-encode and nothing else: no patch, no interpolation, no picture pixel touched. Compare that with cropping the picture to reach the same stamp: the bottom 20 rows are 12,800 pixels, 5.56% of the height and 12.5 times the ink, and 40 rows are 25 times. The bar is the only crop that is free, and the aspect ratio change is the price either way.
Three checks, in the order that saves time. First, is the date even in the file's tags?
ffprobe -v error -show_entries format_tags yourfile.mp4If the time appears there, it is metadata and comes off without touching a frame; the local cleaner removes those boxes in the browser, on MP4 and MOV. If it does not appear, the date is in the picture and the rest of this page applies.
Second, how much of the box is still bright? This prints one number per frame, the average of a mask that keeps pixels at 200 luma or above, so divide by 255 for the share of the box:
ffmpeg -i output.mp4 -vf "crop=172:20:458:334,format=gray,lut=y='if(gt(val\,200),255,0)',signalstats,metadata=print:key=lavfi.signalstats.YAVG" -f null -A share near zero on a clip that had a stamp means it is gone; 1.4% to 1.8% means the box was short. The check has one blind spot worth knowing: a bright background inside the box also counts, so compare against the same measurement on a clean frame or crop the box tighter than the stamp.
Third, compare against a clean copy of the same shot if you have one, inside the box rather than across the frame, because the frame average hides everything:
ffmpeg -i output.mp4 -i clean.mp4 -lavfi "[0:v]crop=172:20:458:334[a];[1:v]crop=172:20:458:334[b];[a][b]psnr" -f null -Every number on this page comes from one script, dev/timestamp_test.py, which builds its own clips with ffmpeg and prints the report quoted above. It needs no image library and no account.
The fixture is synthetic: a still, grained scene with a stamp drawn by drawtext, not a real recording from a camera or a DVR. No camera was used, no recorder menu was tested, and nothing here says which devices burn a stamp and which do not. The numbers describe what the filters did to these frames, on this machine, and the script is the proof.
It also does not evaluate any product's inpainting. The top commercial page for this query, read on 2026-10-19, says it reconstructs the hidden background with AI "across every frame", states no failure conditions, gives no measured numbers, and offers no way to check the result beyond watching a preview; its only hedge is that quality "depends on things like size, placement, and what's going on in the background behind them". That hedge is the entire subject of this page. We did not test that product, and nothing here should be read as a claim about it.
Finally, nothing on this site removes pixels from a video. The cleaner here handles text, images, and the container boxes of MP4 and MOV files; the pixel routes above are ffmpeg's, run by you. A timestamp that is drawn into the frames cannot be restored, only replaced, and every route on this page is a replacement with a visible cost.
Yes, but only by replacing the pixels, never by restoring them. On the 640x360 clip measured here the stamp is 168x16 pixels and 1,026 ink pixels, 0.45% of the frame, and it holds the region at 11.98 dB against a clean copy. A delogo box of 172x20 at (458,334) cleared the stamp in 180 of 180 frames and scored 23.48 dB inside the box, at the cost of rewriting 33.5% of the pixels in it by 20 luma levels or more. If the stamp sits in a black bar, cropping the bar is cheaper: 40 rows removed, no picture lost, 51.33 dB on what survived.
In the picture, if you can see it burned into every frame. On the marked test file ffprobe lists four tags, major_brand, minor_version, compatible_brands and encoder, and none of them holds the date. Stripping every tag with a stream copy left the picture untouched: the result measured PSNR inf against the input and the file stayed at 177,255 bytes, with the stamp still on screen. A date that lives in a tag is a different problem and comes off losslessly; a date that is drawn into the frames does not.
Because the stamp is present in every frame, so the median of any window at a stroke pixel is still a stroke pixel. Measured with ffmpeg's tmedian on a 6-second clip: windows of 9, 45 and 89 frames scored 11.98, 11.98 and 12.04 dB inside the box, against 11.98 dB for the untouched file, and 15.4% to 16.0% of the box stayed at 200 luma or above at every window length. The filter works; the case does not fit it.
It does, because it never reads the digits. delogo rebuilds the rectangle from the ring of pixels around it, so a mark that changes content is no harder than one that does not. On the grained test scene it cleared 180 of 180 frames at 23.48 dB inside the box, with 53.30 dB outside it. What decides the result is the background: the identical box on a scene of vertical stripes scored 73.47 dB and rewrote 0.0% of the box, because stripes are what interpolation can rebuild.
The rest of the frame is never blurred, but it is re-encoded, and that is a real cost. Outside the delogo box the output measured 53.30 dB against the clean original, where a lossless edit would be infinite: those pixels were never marked and still moved, because every frame is decoded and encoded again. If the stamp sits outside the picture in a black bar, cropping the bar avoids the patch entirely and left the surviving picture at 51.33 dB.
Count the bright pixels inside the box, frame by frame, and look at a 4x crop. On this fixture the untouched file had 15.4% to 16.0% of the box at 200 luma or above, the delogo output had 0.00%, and a box that was 2 px short on each side still had 1.41% to 1.82% in 180 of 180 frames, which is a legible ghost. A PSNR number alone cannot tell you this: borrowing a frame from one second later raised the box score from 11.98 to 20.13 dB while putting a different time on screen.