>. However, both prefix their messages with "Warning:" and "Error:" respectively. Also they modify mkvmerge's exit code -- "1" if <code
>mxwarn()</code
> has been used at least once and "2" if <code
>mxerror()</code
> is used. <code
>mxerror()</code
> also instantly exits the program. mmg shows such warnings and errors in separate areas as to draw the user's attention to them. Therefore <code
>mxwarn()</code
> should be used for stuff the user really should know, and <code
>mxerror()</code
> for stuff that prevents further processing altogether.</p
><p
><code
>mxverb()</code
> is a debugging facility. mkvmerge starts out at verbosity level 1. Therefore <code
>mxverb(1, ...)</code
> is equivalent to <code
>mxinfo(...)</code
>. You can raise the verbosity level by adding the "-v" or "--verbose" command line parameters multiple times. Messages output with <code
>mxverb()</code
> should not be translatable, meaning you shouldn't use the <code
>A file and track information storage class. It is created by the command line parser with the source file name and all the command line options the user has passed in.</p
><p
>The instance is then passed to the reader which stores a copy in the <code
>m_ti</code
> variable. The reader also passes that copy to each packetizer it creates which in turn stores its own copy (again in the <code
>A reader is a class that demuxes a certain file type. It has to parse the file content, create one packetizer for each track, report the progress etc. Each reader class is derived from <code
>generic_reader_c</code
> (from <code
>src/merge/pr_generic.h</code
>).</p
><p
>An example for a rather minimal implementation is the MP3 reader in <code
> argument. A virtual destructor must be present, even if it is empty. Otherwise you'll get linker errors.</p
><p
>The constructor must open the file and parse all its headers so that all track information has been processed. This will most likely be split up into a separate function in the future.</p
>read(generic_packetizer_c *ptzr, bool force = false)</code
></a
></h2
><p
>Requests that the reader reads data for a specific track. mkvmerge uses a pulling model: the core asks each packetizer to provide data. The packetizers in turn ask the reader they've been created from to read data by calling this function.</p
><p
>If the reader supports arbitrary access to track data (e.g. for AVI and MP4/MOV files) then the reader should only read data for the requested track in order not to consume too much memory. If the file format doesn't allow for direct access to that data then the reader can simply read the next packet regardless which track that packet belongs to. The packetizer will call the reader's <code
>read()</code
> function as often as necessary until it has enough data.</p
><p
>The reader must return <code
>FILE_STATUS_MOREDATA</code
> if more data is available and <code
>FILE_STATUS_DONE</code
> when the end has been reached.</p
><p
>Each data packet is stored in an instance of <code
>packet_c</code
>. If the source container provides a timecode then that timecode should be set in the packet as well.</p
>Has to create a packetizer for the track with the specific ID. This ID is the same number that the user uses on the command line as well as the number used in the call to <code
>id_result_track()</code
> (see below).</p
><p
>This function has to verify that the user actually wants this track processed. This is checked with the <code
>demuxing_requested()</code
> function. Example from the MP3 reader (as the MP3 file format can only contain one track the ID is always 0; see the Matroska reader for more complex examples):</p
><pre
><code
>// Check if the audio demuxer with ID 0 is requested. Also make
// sure that the number of packetizers this reader has created is
// still 0.
if (!demuxing_requested('a', 0) || (NPTZR() != 0))
return;
// Inform the user.
mxinfo_tid(m_ti.m_fname, 0, Y("Using the MPEG audio output module.\n"));
>A lot of packetizers expect their codec private data to be constructed completely by the reader. This often requires that the reader processes at least a few packets. For a rather complex case see the MPEG PS reader's handling of h264 tracks.</p
>For each supported track the function must call <code
>id_result_track(...)</code
> once.</p
><p
>Both the container and the track identification can contain extended information. For an extensive example see the Matroska reader's identification function in <code
