The MediaStar 920 and 820 are standard-definition digital TV PVRs sold in Australia, manufactured (we believe) by Arion of Korea.
This documentation is based on the initial work of "temporary1" on this thread of the dtv forums with a few more bits that I have added. My examinations were of several files, covering Brisbane channels 2, 7, 9, and SBS. including ABC2, ABC radio, HDTV.
They were analysed for consistency mainly with these perl scripts, although the initial analysis was with hex dump software.
Much of the content is still obscure, but it appears to be either unchanging, or possibly unimportant for playback. It would be expected that some of the information relates to recordings from satellite transmission, but they have not been examined yet. All these files are from the MediaStar 920 terrestrial PVR. It may be the same as files written by other product manufactured by Arion.
Just to confuse everybody, and myself, I might not be consistent in the use of the word "Program". In Mpeg-2 DVB terminology (as far as I can interpret it), a broadcaster (say ABC) transmits a single stream containing multiple programs. This is not a "TV Program" as we mortals normally think of it, but the collection of elementary streams (video, audio, subtitles) that go together for a single, um, channel. So ABC-TV (SD) is a program; ABC-HDTV is another program, ABC-DiG radio is yet another program. I might occasionally call them Program streams to avoid confusing them with a program as in an EPG entry (for example the News, Lateline, etc). This of course conflicts with "mpeg2 program stream", which is the multiplexing method used on DVDs. To make it worse, some web sites explaining mpeg2 over satellite seem to call the Program a channel, and to call what I think of as a channel as a carrier.
There are two file types, with extensions .AVR and .AVF. The Transport Stream data is written to one or more AVR files and the information about the contents are written to the AVF file. The AVR file has little apart from TS data, and is described below. They share a common naming structure, with a format of: <useful_name>_#00<n>_<yyyymmddhhmm>.ext. The "useful_name" is either entered by the user, or derived from EPG program name or channel (program stream) name. The file numbers are incremented from 1 according to the file split. The starting date and time of the recording is included as year-month-day-hour-minutes, so an example might be "The Simpsons_#001_200607281930.AVF
This is always 15160 bytes long
| offset (hex) | size (decimal) and data type | Value (hex) | Description |
| 0 | 4 bytes text "ANRF" : | "ANRF" | fixed header used to identify file |
| 04 | 4 bytes unknown format: | 11 00 00 04, or 12 00 00 04 |
nearly constant. unknown meaning, but the first byte was incremented in the version released early 2007, so perhaps it is is version number |
| 08 | 4 bytes unknown format: | 3f 04 00 0a | constant. unknown meaning |
| Channels, streams PIDs | |||
| 0c | 4 bytes, every channel is different, value for any one channel seems constant, (but they do not scale to broadcast frequency) | 00 07 08 9d 00 11 16 df 00 00 06 ef 00 02 07 7c |
ABC SBS 7 9 |
| 10 | integer-16bit | 6, 8, 11, 12, or 36 | VHF or UHF channel number |
| 12 | 4 bytes unknown format: | 07 00 00 48 | constant, unknown |
| 16 | 2 bytes unknown format | 01 00 02 00 |
all TV ABC radio |
| 18 | integer, 16bit | varies | Service PID |
| 1a | 1 byte | 0 | constant, ?padding? |
| 1b | 1 byte (or maybe this and preceding are 16-bit integer) | 01 02 (rarely) |
Number of audio streams (see offset 0x1e) |
| 1c | integer, 16bit | varies | first audio PID (audio type is defined inside the PES stream but also flagged here: if stream is AC3 then the high bit (0x8000) is set. PIDs are only 13-bits so that is not part of the PID) |
| 1e | integer, 16bit | 7f ff (if 0x1a is 1) variable (if 0x1a is 2) |
second audio stream PID. 0x7fff is the official value for a null PID. |
| 20 | 1 byte | 11 | constant? (not third audio PID) |
| 21 | 1 bytes | 00 or 11 | meaning unknown |
| 22 | integer, 16bit | varies | Video PID |
| 24 | 2 bytes unknown format | 00 00 | constant, always seems to be zero |
| 26 | integer, 16bit | varies | data PID subtitles? |
| 28 | 1 byte | 04 (SBS) 01 other channels |
unknown |
| 29 | 1 byte | values 0 to 5 are common, or 48. | unknown, seems to be constant within a program stream of a channel. It might relate to the Program Map Table from the combined broadcast TS (but I'm guessing, because it is not visible) |
| 2a | 1 byte | 0 | constant, unknown |
| 2b | 25 bytes of text, null padded | "ABC" or "7" | Name of channel (as stored in your list) |
| 44 | 2 bytes unknown format | 01 11 or 00 00 |
half constant, either one value or zero, unknown meaning |
| 46 | 2 bytes unknown format | 0 | constant |
| 48 | 2 bytes unknown format | 0 or 1 | half constant, either one or zero with roughly equal frequency, unknown meaning |
| 4a | 2 bytes unknown format | ||
| 4c | 16 bytes | all 0 | constant (unused?) |
| Initial EPG | |||
| 5c | 714 bytes EPG block (see below) | This is usually the EPG that is current when the recording starts. Sometimes this block is empty, even if there is an EPG table below (maybe this is associated with deleting the lead-in recording at a later time) | |
| AVR file(s) details | |||
| 326 | 126 bytes text (null padded) | Full File pathname to 1st AVR in series. | |
| 3a4 | integer 32bit | 7f 99 00 00 (max) =2140733440 |
Stream size of 1st AVR file. |
| 3a8 | integer 32bit | 7f 99 00 00 | Stream size of second AVR file |
| 3ac ... | as above, repeated for however many files there are (null otherwise) | all file sizes are a multiple of 0x800 | subsequent AVR files... |
| null padding | allows up to 200 files in a recording. That's 400GB, so it's the right size to fill a big disc. The file naming format allows this many. | ||
| 6C4 | integer, 32 bit | usually 5 to 7 million (SD TV) 10 million or more for HD, 300k for radio |
Average broadcast stream rate (bytes/second) for duration of original recording. Not recalculated if you delete chunks of a file. |
| 6C8 | integer, 32-bit | total recording length (in exact minutes only) | |
| 6CC | integer, 16 bit | 00 01 00 02 |
number of files. (matches number of entries in file size table from 0x3a4) |
| 6CE | 2 bytes unknown | 0 | constant, always zero |
| 6D0 | integer - 64bit (this is a guess, but we have so far seen up to 40 bits used) |
a big number. last byte is always zero | total stream size in bytes (sum of 3a4+3a8+...) |
| Bookmarks | |||
| start of bookmark information | |||
| 6D8 | byte | 00 or 01 | usually 1 if there are any bookmarks, zero otherwise, But there are examples showing zero but with bookmanrk!. |
| 6D9 | 7 bytes | all zero | not apparently used. |
| 6E0 | 1 byte | 0 to n | Number of bookmarks in following table |
| 6E1 | 1 byte | 0 to 2 | variable, do not know what this is for. Does not index "last viewed point" |
| 6E2 | 6 bytes | All zero | not apparently used. |
| 6E8 | blocks of 16 bytes, format specification for bookmark below |
start of the number of bookmark records that was specified in 0x6e0 | |
| Recording info | |||
| 1F48 | 2 bytes | 1b ee | constant, probably sync value to mark start of this block |
| 1F4A | integer 16 bit | as for EPG table | When recording was initiated : year |
| 1F4C | 1 byte | When recording was initiated : month | |
| 1F4D | 1 byte | When recording was initiated : day of month | |
| 1F4E | 1 byte | When recording was initiated : hour (24 hr clock) | |
| 1F4F | 1 byte | When recording was initiated : minute | |
| 1F50 | 1 byte | The number of EPG program information blocks that the recording duration covered. Number of EPG blocks in the list. | |
| 1F51 | 1 byte | 0 | unknown, probably just padding for word-alignment |
| EPG Table | |||
| 1F52 | 714 bytes (0x2ca), see EPG format below | EPG record for "now" EPG that was current when the recording started. This will often be the program before the one you wanted, if you started recording a bit early. | |
| 221C | 714 bytes | The second EPG record that was broadcast as "now" during the recording. | |
| 24E6 | info of 3rd file… 714 bytes each file… Space for 10 files? | The third EPG recorded, etc. Possibly space for 10 records. Filled with nulls if no record. |
Note: Stream size refers to the number of bytes that are part of the TS stream in the file. As far as we know it is always the total file size minus 0x8000 (32k decimal)
Note: bitratecalculation: This value seems to be used to relate location in file (byte offset) with the time at that position. In reality the value varies slightly with the exact recording, but a single constant is assumed for those purposes. For example, record two programs A and B into one file, and record program B separately. They will have slightly different bitrates - channels themselves broadcast at markedly different bitrates from each other, depending on how many streams they want to cram in). Then delete program A from the first file. The saved bitrate in the first recording AVF is left unchanged and will not match that in the second file. It is unlikely this will be noticeable.
This is the format of each EPG block. It seems to be just what the TV station broadcasts, and it may or may not get changed when chunks of the file are deleted. Each block is 714 decimal (0x2ca) bytes long.
| offset into block | size and data type | typical value | meaning |
| 0 | integer, 16 bit | 02 ca | constant -synch word indicating start of EPG block (NB it is also the size of each block (including this word)) |
| 2 | integer 16 bit | 07 d6 | program starttime : year (e.g. 2006) |
| 4 | byte | 01 to 0c | program starttime : month (1 = Jan, 2 = Feb, etc) |
| 5 | byte | 01 to 1f | program starttime : day of the month |
| 6 | byte | 00 to 17 | program starttime : hour (24 hour clock) |
| 7 | byte | 00 to 3b | program starttime : minutes |
| 8 | byte | 00 to 17 | Duration of program in EPG : hours (yes ABC radio currently has single entry lasting 24 hours) |
| 9 | byte | 00 to 3b | Duration of program in EPG : minutes |
| a | 64 bytes text null padded, or truncated (last byte always null) |
Program title | |
| 4a | 128 bytes text null padded, or truncated (last byte always null) |
Subtitle (Often actually used for the description) | |
| ca | 512 bytes text null padded, or truncated (last byte always null) |
Description (often empty) | |
| 2ca | start of next EPG |
This is the format of bookmarks. I cannot see how it saves the "point at which you stopped viewing". There is a bookmark for it, but it is not apparent how it differs from the others.
Each record is 16 (decimal) bytes long
| offset into block | size and data type | typical value | meaning |
| 0 | 4 bytes, format unknown | 10 00 00 10 | constant, meaning unknown |
| 4 | 1 byte | 0x11 or 0x01 | variable, meaning unknown |
| 5 | 3 bytes | 00 00 00 | constant, meaning unknown |
| 8 | integer 64 bit. | a big number | this is the byte offset into the stream where the bookmark is located. The curious thing is that I can find no common divisor (beyond 4), They are certainly not all aligned to TS packet boundaries. |
The file system is fat-32, and so each file cannot exceed 4GB. In fact, it seems to be artificially lowered and so video files are split so that they are never more than 0x7f990000 bytes of TS data. This is a total file size of 2140766208 bytes. A likely reason for this is that this size occurs at a TS packet boundary, and also at a FAT-32 cluster boundary, so probably relates to I/O efficiency. If the files are edited, they always remain multiples of 32k. Packets padded with nulls are sometimes observed.
Each video file in a multi-part recording has the same header. There is only ever one AVF file per recording.
| offset (hex) |
size and data type | typical value | meaning |
| 0 | 4 bytes text | "ARAV" | constant, fixed header used to identify file |
| 4 | 2 byte, format unknown | 0x10 0x00 | constant, meaning unknown |
| 6 | 2 bytes, format unknown | 0x00 0x86 | constant, meaning unknown |
| 8 | 2 bytes, possibly 16-bit integer | 0x80 0x00 | constant, happens to be the header size (in bytes) |
| 0a | 126 bytes text (null padded) I presume it is 126 bytes, in parallel to the AVF format. |
"C:\PVR\AV\xxx.AVF" | Full file pathname to corresponding AVF file. |
| The remainder of the header (32k) is null padded to the start of the TS stream data. |