Overlay Time & Date Code On MPEG-2 File

[huykin]

Thanks. Regarding the player, I don't think my Philips DVP5990 can show date/time from these Sony MPEG2 files directly. What it can do is play MPEG2 files without DVD authoring, and show subtitles (for both MPEG2 and DivX) added as separate files in several formats including SRT and MicroDVD SUB. Don't know if it can show subtitles embedded in DivX files, as I don't have any of those. Since the date/time info is contained in these Sony MPEG2 files, theoretically it can be extracted and displayed "on the fly" when playing a file. I just wonder if there is any hardware or software solution that can actually do that.

By the way, I found that several programs can easily convert MicroDVD SUB subtitles to SRT. (One just need to set the correct frame rate.) Probably the easiest of them is SubTool. So now I can do a 3-step process to get SRT date/time subtitles for these Sony MPEG2 files:

1. Your prog to get DVDT from MPG.
2. DV Sub Maker to convert DVDT to MicroDVD SUB.
3. SubTool to convert MicroDVD SUB to SRT.

Probably not the most efficient way, but it works. Now the challenge is to figure out a batch process for each of these 3 steps...

[huykin]

Regarding my player's support for subtitles embedded in DivX files, page 30 of its manual (attached) says that in addition to SRT and other external subs, it supports XSUB subs as a part of DivX Ultra support. I don't use those, but believe they are special image-based subs embedded in DivX 6+ files with possibility of multiple subs in a file, similar to those in DVD VOB files.

philips%20dvp5990.pdf

[duffycoug]

I'm very new at this...just bought a Sony DCR-SR68 and it records in MPEG-2 format...when I transfer to computer there is not "time and date" displayed on the screen. It shows on my camera when I hit datacode, but it doens't show on my computer. This is ridiculous. How can I add the time and date to my videos before I burn them onto the DVD...I hope there's a simpler way than what is posted, because I'm completely lost with those instructions.

THANKS!

UPDATE: Ok, I used the method described and got the time and date to show up, but is that now part of the original file and will it show when I burn that to a DVD? Guess I'll have to try that to find out. Also, is there a way to make the subtitle move to the lower right corner of the screen like it shows on the camera itself? That would be very useful.

Thanks

[clunesy]

Ridiculously old thread, but anyone trying to get date info out of old files (mine had long since been copied multiple times and lost all dates), it is buried in the stream by Sony. Managed to get the info back from my DC-SR72E files

Claude analysed two short files and found where its stored, and wrote a python script.


# Where Sony Handycam MPEG-2 camcorders hide the recording date/time

A precise, reproducible description of where the wall-clock recording timestamp
is stored inside the `.MPG` files written by Sony hard-disk-drive "Handycam"
camcorders, and how to decode it. Written because the original tools that read
this (e.g. `infompg.exe` from the VideoHelp/Sony forums) are long dead and
closed-source.

## What this applies to

- Confirmed on the **Sony DCR-SR72E** (PAL HDD Handycam), files from 2007–2010.
- Expected to hold across the same-era **DCR-SR / DCR-DVD** HDD/DVD MPEG-2 family.
- The files are the `M2U#####.MPG` clips the camera records (the same ones Sony
Picture Motion Browser / PMB imports).
- The camera model is stored verbatim as ASCII inside the file, so you can
confirm a file is in scope before trusting the offset (see below).

The timestamp is **not** in the video stream, **not** EXIF, and **not** in
`private_stream_2`. Standard players and FFmpeg never show it, and it is
**destroyed by any re-encode or careless remux** — so extract it from the
originals before transcoding.

## TL;DR

The recording time is a **packed 32-bit big-endian integer** at **offset
`0xA4`** inside each Sony `ARI_DATA` metadata block. Those blocks ride in PES
packets with **stream_id `0xBD` (`private_stream_1`), sub-stream id `0xFF`**.
The **first** `ARI_DATA` block in the file is the instant recording started.

Decode (where `v` is the big-endian uint32 at offset `0xA4`):

```
year = ((v >> 26) & 0x3F) + 1984
month = (v >> 22) & 0x0F
day = (v >> 17) & 0x1F
hour = (v >> 12) & 0x1F
minute = (v >> 6) & 0x3F
second = v & 0x3F
```

Times are the **camcorder's local clock**. No timezone or UTC offset is stored.

## Container layout

The `.MPG` files are **MPEG-2 Program Streams** (pack headers `00 00 01 BA`
wrapping PES packets), not Transport Streams. Three logical streams are present:

| stream_id | contents | seen by FFmpeg? |
|------------------|---------------------------------------------|-----------------|
| `0xE0` | MPEG-2 video, 720×576i25 (PAL) | yes |
| `0xBD` sub `0x80`| AC-3 audio, 48 kHz stereo | yes |
| `0xBD` sub `0xFF`| **Sony private metadata (timestamp etc.)** | **no — dropped**|

Sub-stream `0xFF` of `private_stream_1` is where everything interesting lives.
FFmpeg's MPEG-PS demuxer silently discards it, which is why no normal tool
surfaces the date.

Inside that sub-stream there are two record types, each tagged with an 8-byte
ASCII name immediately after the `0xFF` sub-stream byte:

- **`MVI_DATA`** — an index/pointer block. Holds the model string and a table of
GOP/pack offsets (it literally stores the file's total pack count). *Not* the
clock.
- **`ARI_DATA`** — camera settings **and the recording timestamp**. This is the
one you want. Blocks recur roughly every ~512 KB; the first sits ~2 KB into
the file.

## Locating the bytes — the robust way (parsing the stream)

1. Walk the Program Stream pack-by-pack:
- At `00 00 01 BA` (pack header), skip 14 bytes **plus** the pack-stuffing
length held in the low 3 bits of byte 13.
- At `00 00 01 BB` (system header) and any PES packet `00 00 01 xx`, read the
16-bit length at bytes 4–5 and skip the packet.
2. For PES packets with stream_id **`0xBD`**:
- The 3rd byte of the PES payload is `PES_header_data_length`. Skip the PES
header: payload data begins at `3 + PES_header_data_length`.
- The **first byte of that payload data is the sub-stream id**. `0x80` = the
AC-3 audio; **`0xFF` = Sony metadata**.
3. In a `0xFF` payload, bytes 1–8 are the ASCII tag. Keep the ones equal to
`ARI_DATA`.
4. Read the **big-endian uint32 at offset `0xA4`** of that payload (offset
measured from the `0xFF` sub-stream byte = byte 0 of the payload).
5. Decode with the masks above. The first `ARI_DATA` block = recording start;
later blocks carry the same value with the seconds field advancing.

## Locating the bytes — the quick way (hex editor)

1. Search for the ASCII string `ARI_DATA`. The `0xFF` sub-stream marker is the
single byte immediately before the `A`.
2. From that `0xFF` byte, count **`0xA4` (164) bytes forward** — equivalently,
`0xA3` (163) bytes from the `A` of `ARI_DATA`.
3. Read **4 bytes, big-endian**. That is the packed timestamp.
4. Decode. The first occurrence in the file is the recording start.

What it looks like in the file (offsets relative to the `0xFF` marker):

```
0x0000: FF 41 52 49 5F 44 41 54 41 ... FF "ARI_DATA"
...
0x00A0: FF 10 3C 1F 5D A5 1B 60 ... timestamp (BE u32) at 0x00A4
└─────────┘
5D A5 1B 60
```

## The packed format in detail

The 32 bits, most-significant first:

| bits | width | field | range / note |
|--------|-------|---------------|----------------------|
| 31–26 | 6 | year | value **+ 1984** |
| 25–22 | 4 | month | 1–12 |
| 21–17 | 5 | day | 1–31 |
| 16–12 | 5 | hour | 0–23 |
| 11–6 | 6 | minute | 0–59 |
| 5–0 | 6 | second | 0–59 |

### Worked example 1 — `M2U00003.MPG`

Bytes at `0xA4`: `5D A5 1B 60` → `v = 0x5DA51B60`.

```
0101 11 | 0110 | 10010 | 10001 | 101101 | 100000
year=23 mo=6 day=18 hr=17 min=45 sec=32
+1984
=2007
```

→ **2007-06-18 17:45:32** (Monday)

### Worked example 2 — `M2U00066.MPG`

Bytes at `0xA4`: `5E 3F 58 6F` → `v = 0x5E3F586F`.

```
0101 11 | 1000 | 11111 | 10101 | 100001 | 101111
year=23 mo=8 day=31 hr=21 min=33 sec=47
+1984
=2007
```

→ **2007-08-31 21:33:47** (Friday)

## How we know the layout is correct

This format isn't publicly documented; it was pinned down empirically, and the
evidence is strong enough to trust:

- **Differential analysis.** Comparing `ARI_DATA` blocks across two clips
recorded on different days, and across the multiple blocks within one clip,
isolated a small cluster of bytes at `0xA4`. Bytes `0xA4`–`0xA6` are constant
within a single recording but differ between recordings (date components);
byte `0xA7` is the only one that advances within a single clip.
- **The seconds field tracks real elapsed time.** In a 3.4-second clip the value
walked `…:32 → …:35`; in a 1.4-second clip it walked `…:47 → …:48`. The
decoded seconds match the actual video duration block-for-block.
- **The field widths are forced, not guessed.** A decoded `second = 47` (> 31)
proves the seconds field is 6 bits wide, not 5. That fixes the whole 6-6-5-5-4
layout for the lower 26 bits, leaving exactly 6 bits for the year — and a
6-bit field reading 23 for known-2007 footage forces the **+1984** base.

## Practical notes

- **Read only the head of each file.** The first `ARI_DATA` block (the start
time) is within the first ~2 KB; reading ~2 MB is more than enough. Do **not**
read whole multi-GB files — over a network share that is what makes naive
tools appear to hang.
- **Local time.** The stamp is whatever the camera's clock was set to. Apply your
own timezone/DST knowledge if you need UTC.
- **It does not survive transcoding.** The `0xBD`/`0xFF` stream is stripped by
re-encoding and by remuxers that don't preserve private streams. Capture the
date (e.g. write it to a sidecar, or set the file's modified-time) from the
original `.MPG` before it enters any FFV1/AV1 pipeline.
- **The +1984 base** is the one value to re-verify if you ever feed this footage
you *know* falls well outside ~1984–2047 and the decoded year looks off by a
fixed amount. Everything else in the layout is locked by the field widths.