Recorded Files
From OpenWiz
Contents |
File Naming Convention
TV recordings are created in a directory named in the following format:
- Title_MMM.DD.YYYY_HH.NN.tvwiz
Radio recordings are created in a directory named in the following format:
- Title_MMM.DD.YYYY_HH.NN.radwiz
MMM = 3 letter month
DD = 2 digit date (day)
YYYY = 4 digit year
HH = 2 digit hour (in 24 hour format)
NN = 2 digit minute
TV and Radio recordings are stored in the beyonwiz's recording directory.
- TV recordings are only visible to the user when Movie mode is selected.
- Radio recordings are only visible to the user when Music mode is selected.
In 24 hour mode the user sees recordings as:
- DD/MM/YY HH:NN (## min) Title
In 12 hour mode the user sees recordings as:
- DD/MM/YY HH:NNam (## min) Title
- DD/MM/YY HH:NNpm (## min) Title
Note: The channel name will be used as the title if the program's title is unavailable:
- DD/MM/YY HH:NN (## min) ChannelName
--Dave® 03:09, 21 March 2008 (UTC)
Recording Directory Contents
Each recording's directory contains 3 binary files - a header file, a trunc file and a stat file - and as many 32MB mpeg-ts files as needed. The mpeg-ts files have no file extension and normally start at 0000 with each consecutive file's name incremented by 1. i.e. 0001, 0002, 0003 and so on. The last file can be 32MB or smaller.
Note: If you have edited a recording, or saved part of the timeshift buffer, the numbered 32MB files may not start at 0000. File sets need not be complete - i.e. the numered sets can have gaps as long as the trunc file has been updated accordingly.
header.tvwiz & header.radwiz files
Contains all the LCN and channel information.
It is always 256 KB (262,144 bytes).
Acknowledgment: Much of the information in this section is derived from the Beyonwiz WizFX source code and the Beyonwiz WizPnP Protocol description. The source code license says "Any adaptation and/or re-distribution of this program is/are allowed."
header.tvwiz file layout
+---------------------+ < offset 0 (0x00000)
| |
| TVWizFileHeader |
| |
+---------------------+ < offset 24 (0x00018)
| |
| ... |
| |
+---------------------+ < offset 1024 (0x00400)
| |
| TVWizTSPoint |
| |
+---------------------+ < offset 1548 (0x0060c)
| |
| TVWizTSPoint.offset |
| |
+---------------------+ < offset 69128 (0x10e08)
| |
| ... |
| |
+---------------------+ < offset 79316 (0x135d4)
| |
| TVWizTSbookmarks |
| |
+---------------------+ < offset 79856 (0x137f0)
| |
| TVWizTSextInfo |
| |
+---------------------+ < offset 81140 (0x13cf4)
| |
| ... |
| |
+---------------------+ < offset 262144 (0x40000)
Prl 05:32, 1 April 2008 (UTC)
offset 0 - 4 bytes (hex): 62 10 02 00
offset 1024 - varies (text): Channel-Name
offset 1280 - varies (text): FAV-Group - LCN - Title
offset 1536 (hex): ?unknown?
offset 79316 - 1 byte (hex): Number of Bookmarks
offset 79336 - 3 bytes (hex): First Bookmark.
offset 79344 - 3 bytes (hex): Second Bookmark.
offset 79352 - 3 bytes (hex): Third Bookmark.
Each successive bookmark starts 6 bytes after the end of the preceding bookmark. Maximum quantity of bookmarks?
TVWizFileHeader
struct TVWizFileHeader { /* File offset 0 */
ushort hidden[6]; /* File offset 0 */
uchar lock; /* File offset 12 (0x0c)
* parental lock (?)
*/
uchar mediaType; /* File offset 13 (0x0d)
* media type
* 0 = video, 1 = audio, 2 = photo (?)
*/
uchar inRec; /* File offset 14 (0x0e)
* currently recording
* if non-zero.
*/
uchar unused; /* File offset 15 (0x0f) */
};
The data types in the example follow C conventions: char: 8-bit signed or unsigned - architecture dependent; uchar: 8-bit unsigned; ushort: 16-bit unsigned; ulong: 32-bit unsigned; uint64: 64-bit unsigned. The structures are assumed to be packed as tightly as possible, all padding is explicit or for the start of structures, implied by the file offset. Multi-byte values are in the Beyonwiz's ARM CPU's native littlendian format; that is the lowest file offset is the least significant byte. This is the same byte order as Intel x86 processors.
There's currently no information about the unknown field. For TV recordings, the first two elements of the array appear to have constant values. The interpretation of lock and mediaType is uncertain. Media type in WizFX is determined by whether the recording contains a header.tvwiz (for TV) or a header.radwiz (for radio) file.
If inRec is non-zero, the recording is currently being recorded. Copying it from the Beyonwiz may result in a corrupted copy on the destination.
Prl 05:32, 1 April 2008 (UTC)
TVWizTSPoint
struct TVWizTSPoint { /* File offset 1024, 0x400 */
char svcName[256]; /* File offset 1024, 0x400
* service (LCN) name. NUL padded.
*/
char evtName[256]; /* File offset 1280, 0x500
* program title (event name). NUL padded.
*/
ushort mjd; /* File offset 1536, 0x600
* Recording start time, as a Modified
* Julian Date, but not really
* MJD, strictly speaking.
* See text.
*/
ushort pad; /* File offset 1538, 0x602 - Alignment */
ulong start; /* File offset 1540, 0x604
* Recording start time, seconds
* past midnight on the MJD.
*/
ushort last; /* File offset 1544, 0x608
* Index of the last valid
* navigation offset in
* offset.fileoff[].
* Navigation offsets are at 10
* second intervals, so
* the recording duration is
* duration = last*10 + sec
* The offset at last+1 is also
* set to zero. Non-zero offsets
* may follow, but are not relevant.
*/
ushort sec; /* File offset 1546, 0x608
* Recording duration (sec)
* beyond the last navigation
* offset.
*/
struct TOffset offset; /* File offset 1548, 0x60c
* Recording navigation index.
* Offset of end of recording
* and recording offsets every
* 10 sec.
*/
};
svcName and evtName are the broadcast service (strictly the name of the LCN or logical channel number) that made the recorded broadcast and the program title (or event name if set from the EPG).
mjd and start make up the start time for the recording. Although its name suggests that the start time is a Modified Julian Date, which is "the number of days ... that have elapsed since midnight at the beginning of Wednesday November 17, 1858 [Universal Time]". The timestamp is in fact the MJD plus the time zone offset current at the time the recording started.
To make sense of this time scheme, you can translate the recording start time into local time in C or (or similarly in Perl) on Unix-like systems using:time_t startt; struct tm *locatime; startt = (wizTSPoint.mjd - 40587) * 24 * 60 * 60 + wizTSPoint.starttime; localtime = gmtime(&startt); /* now the fields of localtime are correct for local time at the start of the recording */
In particular, note that although startt is similar to the Unix time, it should not be converted into the local time date/time information in struct tm by using localtime(3) as it normally would be. To convert the time into a true UTC-based Unix time, set TZ to the timezone that was in effect at the time of the recording, and call mktime(3) on startt.
offset provides a navigation index into the recording, allowing a point in elapsed time in the recording to be mapped into an approximate position in the recording file by interpolation.
offset.fileOff contains offsets into the logical recording file described by the trunc file. The offsets represent the starts of 10-second intervals of the recording, possibly aligned to the start of an MPEG I-frame.
last is the index of the last valid navigation offset in offset.fileoff[]. Because the navigation offsets are at 10 second intervals, the recording duration is duration = last*10 + sec. The offset at last+1 is also set to zero. Non-zero offsets may follow, but are not relevant.
sec is the time between offset.fileFF[last] and offset.lastOff.
Prl 05:32, 1 April 2008 (UTC)
TOffset
TOffset provides a navigation index into the recording, allowing a point in elapsed time in the recording to be mapped into an approximate position in the recording file by interpolation.
Its operation is described above in TVWizTSPoint.
There are up to 8640 entries each representing a 10-second interval, allowing a recording up to 86400 seconds (or one day) long to be indexed. The fileOff part of the index describes 86390 seconds of recording, and the the interval from fileOff[8639] to lastOff may be an additional 10 seconds.
fileOff[0] is always 262144, the length of header.tvwiz, suggesting that the header is considered part of the logical recording.
struct TOffset { /* File offset 1548, 0x60c */
uint64 lastOff; /* File offset 1548, 0x60c
* Offset of end of recording
*/
uint64 fileOff[8640]; /* File offset 1556, 0x614 */
* Table of offsets in the recording
* at 10-sec intervals. Terminated
* by an offset of 0.
*/
};
TVWizTSbookmarks
The TVWizTSbookmarks section of the header describes bookmarks in the recording. The structure of this part of the file is not documented in WizFX source code nor in the Beyonwiz WizPnP Protocol description.
struct TVWizTSbookmarks {
ushort numBookmarks; /* File offset 79316 (0x135d4)
* Count of the number of bookmarks.
* May be more space than 16 bits,
* but there's "only" room for
* 22776 bookmarks, so 16 bits
* is easily enough.
*/
uchar pad[18]; /* File offset 79318 (0x135d6) */
uint64 bookmarks[64]; /* File offset 79336 (0x135e8)
* Table of bookmark offsets,
* sorted in time order.
* Count in numBookmarks;
* actual maximum size uncertain,
* probably 64, but certainly
* no more than 65.
*/
};
The structure is very straightforward. The actual length of numBookmarks is not known, but an unsigned 16-bit integer is easily large enough to contain the number of bookmarks that can follow given the (apparently fixed) size of the header. It's possible that it is in fact stored as a ulong, which would make the padding 16, rather than 18 bytes. It's possible that the "padding" space is actually reserved for the implementation of a resume play offset.
Each bookmark is an offset into the logical recording file, as described in trunc file and in TOffset. The offset of the start of actual recorded material is 262144.
It is also not known whether the whole remaining header is reserved for bookmarks, or whether there is other reserved space past the end of the bookmark table.
The bookmarks are ordered to be at least non-descending by their offset. They are probably in fact in strict ascending order (i.e. no bookmarks with the same offset).
Bookmarks are currently copied when the header.tvwiz file is copied either by WizFX (or similar programs) or by the Beyonwiz copy function. However, at the moment, the Beyonwiz can't delete or add bookmarks to a recording on a network share. Once the bookmark has been copied to a share, all bookmarks can be deleted by zeroing out the bookmark area of the file; simply setting numBookmarks to zero will probably suffice. Adding bookmarks to the header is also simple, but the alignment requirements of the offsets are unknown. For a clean visual transition, the bookmarks should probably be aligned to the start of an I-frame. Using existing offsets from the TOffset table may provide bookmark offsets that are suitably aligned, though they are only available at 10-second intervals.
TVWizTSextInfo
The TVWizTSextInfo section of the header contains the recording episode name and extended event information (program synopsis). The structure of this part of the file is not documented in WizFX source code nor in the Beyonwiz WizPnP Protocol description.
struct TVWizTSextInfo {
uchar episodeLen; /* File offset 79856 (0x137f0)
* Episode name length, 0..255
*/
char episodeName[255]; /* File offset 79857 (0x137f1)
* Episode name text
*/
ushort extInfoLen; /* File offset 80114 (0x138f2)
* Extended event information
* length, 0..1024.
*/
char extInfo[1024]; /* File offset 80116 (0x138f4)
* Extended event information text
*/
};
stat file
I'm not sure what this file is used for yet.
It is always 96 bytes
offset 46 - 2 bits (hex): ?unknown?
--Dave® 03:09, 21 March 2008 (UTC)
trunc file
Contains all the information needed to construct a single logical recording file from the 32MB (and smaller) MPEG-TS files that make up the recording.
Once they have been created by a recording, the MPEG-TS files don't seem to be changed in size by editing operations (except perhaps the new files created when a Copy A->B operation is done). The information about how to assemble the (pieces of the) MPEG-TS files into a single logical recording is held in the trunc file.
Contains all the information about the quantity and names of all of the 32MB (and smaller) mpeg-ts files.
struct TwizOffsetFileSection {
uint64 wizOffset; /* Offset 0 (0x00)
* Logical offset of the start
* of the file chunk in the
* recording. The wizOffset of
* the first trunc entry is always
* 262144.
*/
ushort fileNum; /* Offset 8 (0x08)
* File number containing
* the recording chunk.
*/
ushort flags; /* Offset 10 (0x0a)
* Unknown purpose. Never
* referred to by WizFX.
*/
uint64 offset; /* Offset 12 (0x0c)
* Offset of the recording
* chunk in file fileNum.
* Size overkill, because recording
* files are never larger than
* 32 MB (33554432 bytes).
*/
ulong size; /* Offset 20 (0x14)
* Size of the recording chunk.
*/
};
The trunc file consists of a sequence of 24-byte TwizOffsetFileSection records, one for each chunk of the MPEG-TS files that makes up the logical recording file. More than one TwizOffsetFileSection record may refer to a single MPEG-TS file, but the limited nature of the editing operations on the Beyonwiz ensures that trunc files created and edited on the Beyonwiz will always have any multiple references to the same MPEG-TS file adjacent and in order of increasing offset, and the values of the fileNum fields will be non-decreasing. It is possible, though, that the Beyonwiz playback code does not depend on this ordering, and the trunc file could be used for general cut/splice operations. The cut/splice positions probably need to be on I-frame boundaries.
wizOffset is the offset of the start of the chunk in the logical recording file. As with the offsets in TOffset, the start of the recording material is at offset 262144. The records in the trunc file must be ordered so that the wizOffset fields are in ascending order, and increase by exactly the size field.
Prl 06:14, 1 April 2008 (UTC)
Download html version of image for editing
Each 'line' referred to below refers to 24 bytes.
- Last byte: Each 24 byte line always ends in either 00, 01 or 02.
The first and last line always ends in either 00, 01 or 02.
All other lines always end in 02.
- 2nd last byte: The 2nd last byte on each first and last 24 byte line varies.
I've seen 00, 06, 60, 80 and E4.
All lines between the first and last have 00 as the 2nd last byte.
- 1st 3 bytes: Each 24 byte line almost always starts with 00 00 04.
Except sometimes the first line starts with 00 00 A4 instead of 00 00 04.
- 4th byte: On each 24 byte line the 4th byte increments by 2 hex from the last line's 4th byte.
Usually the first line's 4th byte is 00 but sometimes it starts at a larger number.
- 9th byte: The 9th byte on each 24 byte line increments by 2 hex from the last line's 9th byte.
Usually the first line's 9th byte is 00 but sometimes it starts at a larger number.
- 10th byte: The 10th byte on each 24 byte line increments by 2 hex for every 255 lines in the file.
When record 255 + 1 has been reached, the 9th byte resets to 00 and we start counting again.
- 15th byte: In one file the 15th byte on the first line was A0 (in all other files it was 00).
This particular recording was saved from the timeshift buffer.
All other bytes are 00
Notes:
The 4th byte is always double the value of the 9th byte.
The 9th byte is the hex value of the part file's number.
If the part files start with 0000 the 9th byte on the first line will be 00.
And the 4th byte on the first line will be 00.
On a 85 file set starting at 0000 and ending at 0084:
The last line's 9th byte would be 55.
And the last line's 4th byte would be AA.
File sets can start at any number:
i.e. Starting at 0083 and ending at 0089 etc (if recorded from the timeshift buffer)
--Dave® 03:09, 21 March 2008 (UTC)
