IVR: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
mNo edit summary
(add description)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
*Company: [[Real]]
*Company: [[Real]]
*Sample: http://www.skyshedpod.com/SherwinWilliamsCommercial.ivr
*Sample: http://samples.mplayerhq.hu/real/ivr/


IVR is a recorded media format created by Real Player 11.
IVR is a recorded media format created by Real Player 11.
The file can either be a single record (starting with <code>.REC</code> magic) or a collection of records (starting with  <code>.R1M</code> magic).
Data is stored in big-endian format.
=== R1M header ===
4 bytes - .R1M
3 bytes - unknown, always 0, 1, 1 ?
4 bytes - file name length
N bytes - file name
1 byte  - always 0?
4 bytes - additional header length
8 bytes - entries offset
Entries start with a byte containing entry type and 4-byte payload size, the rest of data is interpreted depending on it:
* 1 - some metadata, probably for the following sub-recording
* 2 - sub-recording in <code>REC</code> format with some additional header
* 82 (or <code>'R'</code>) - signals that this is really some <code>RJMx</code> metadata chunks at the end of file
=== REC format ===
The format consists of header and entries with different payload like stream metadata or data packets, a lot like e.g. [[FLV]].
Header:
4 bytes - .REC
1 byte  - always zero?
4 bytes - number of entries
Each entry starts with a byte specifying its payload type:
* 1 - stream properties, payload starts with 32-bit number of properties, the properties are in the same format as <code>.REC</code> entries themselves (types 3-5);
* 2 - packet:
  4 bytes - timestamp
  2 bytes - stream ID
  4 bytes - packet flags
  4 bytes - packet payload length
  4 bytes - header fields checksum?
  N bytes - RealMedia packet payload
* 3 - integer record:
  4 bytes - key name length
  N bytes - key name
  4 bytes - value length (should be 4)
  4 bytes - integer value
* 4 - binary data:
  4 bytes - key name length
  N bytes - key name
  4 bytes - value length
  M bytes - binary data value
* 5 - string data
  4 bytes - key name length
  N bytes - key name
  4 bytes - value length
  M bytes - value string
* 6 - header end marker
* 7 - data end marker, has 8 zero bytes of payload
* 8 - data start marker, has 8 zero bytes of payload
Normally the structure for the recording is the following:
* several entries with types 3-5 for recording metadata
* one or more stream properties
** each has several sub-entries with types 3-5 for stream metadata
* header end marker
* three 4-byte offsets
* seek table (if signalled to be present in the metadata)
* data start marker
* one or more packets
* data end marker


[[Category:Container Formats]]
[[Category:Container Formats]]
[[Category:Formats missing in FFmpeg]]

Latest revision as of 03:22, 27 February 2021

IVR is a recorded media format created by Real Player 11.

The file can either be a single record (starting with .REC magic) or a collection of records (starting with .R1M magic).

Data is stored in big-endian format.

R1M header

4 bytes - .R1M
3 bytes - unknown, always 0, 1, 1 ?
4 bytes - file name length
N bytes - file name
1 byte  - always 0?
4 bytes - additional header length
8 bytes - entries offset

Entries start with a byte containing entry type and 4-byte payload size, the rest of data is interpreted depending on it:

  • 1 - some metadata, probably for the following sub-recording
  • 2 - sub-recording in REC format with some additional header
  • 82 (or 'R') - signals that this is really some RJMx metadata chunks at the end of file

REC format

The format consists of header and entries with different payload like stream metadata or data packets, a lot like e.g. FLV.

Header:

4 bytes - .REC
1 byte  - always zero?
4 bytes - number of entries

Each entry starts with a byte specifying its payload type:

  • 1 - stream properties, payload starts with 32-bit number of properties, the properties are in the same format as .REC entries themselves (types 3-5);
  • 2 - packet:
 4 bytes - timestamp
 2 bytes - stream ID
 4 bytes - packet flags
 4 bytes - packet payload length
 4 bytes - header fields checksum?
 N bytes - RealMedia packet payload
  • 3 - integer record:
 4 bytes - key name length
 N bytes - key name
 4 bytes - value length (should be 4)
 4 bytes - integer value
  • 4 - binary data:
 4 bytes - key name length
 N bytes - key name
 4 bytes - value length
 M bytes - binary data value
  • 5 - string data
 4 bytes - key name length
 N bytes - key name
 4 bytes - value length
 M bytes - value string
  • 6 - header end marker
  • 7 - data end marker, has 8 zero bytes of payload
  • 8 - data start marker, has 8 zero bytes of payload

Normally the structure for the recording is the following:

  • several entries with types 3-5 for recording metadata
  • one or more stream properties
    • each has several sub-entries with types 3-5 for stream metadata
  • header end marker
  • three 4-byte offsets
  • seek table (if signalled to be present in the metadata)
  • data start marker
  • one or more packets
  • data end marker