[mythtvnz] recorded programmes file format

[Paulgir]

>
> MythTV recordings from DVB or ATSC devices or the like are MPEG
> Transport Stream format, copied directly from the digital data
> received from the tuner, hence the .ts file extension.  Recordings
> from an old analogue tuner are MPEG Program Stream format, which is
> supposed to have the .mpg file extension.  Up until 0.28, the
> transport stream recordings where being given the wrong .mpg file
> extension, and this has now been corrected.  But it does not matter
> much, as all MPEG files, whatever format, have headers at the start
> that allows the correct format to be determined.  So most software
> that plays video files, including MythTV, ignores the file extension
> and determines the file format from those headers.  If you want to
> know the format of a video file, use the mediainfo command on it.  In
> the top section of the output (General), the Format line tells you the
> real format of a file.  Here is an example from a .mpg file I recorded
> earlier this year from TV One using 0.27:
>
> General
> ID                                       : 27 (0x1B)
> Complete name                            : 1001_20160102032900.mpg
> Format                                   : MPEG-TS
> File size                                : 2.04 GiB
> Duration                                 : 34mn 57s
> Overall bit rate mode                    : Variable
> Overall bit rate                         : 8 366 Kbps
>
> You can see it is actually a Transport Stream file (MPEG-TS as opposed
> to MPEG-PS).
>
> The difference between Transport Stream and Program Stream format is
> not huge.  Transport stream files have a bit of extra redundant data
> for error checking and error correction, so that errors that creep in
> between the transmitter and receiver can be handled.  They also tend
> to use smaller block sizes for the data in each stream, and organise
> the relative positioning of the blocks of data in each stream so that
> the buffering requirements in the receiver are minimised.
>
> MythTV has never transcoded digital recordings on the fly when
> recording - that is done after the recording ends or in parallel, with
> the recording and transcoded recording being in separate files.  And
> it is only done if the user sets it up to happen.  With analogue
> recordings, if the analogue tuner is not capable of doing the
> transcoding necessary for a sane file size in hardware, MythTV
> supports doing on the fly transcoding as part of the recording
> process.  Without such transcoding, an ordinary PAL TV recording
> stored in uncompressed AVI format would need around 1.1 Gibytes per
> minute!  But you have to have a fast processor to support transcoding
> - it needs to be fast enough to encode faster than the frame rate
> being received.  Back when analogue recordings were normal, the
> processors were not really fast enough so everyone used tuners with
> hardware encoding, or used a very expensive CPU and recorded only one
> channel at once.  Current processors are often capable of encoding one
> channel per CPU core at the standard TV frame rates, and that is what
> now makes mythcommflag able to be run in parallel with a recording and
> get its data from the RAM buffers for the recording, instead of having
> to read the data back from the disk.  The processing needed to do
> commercial flagging is pretty similar to that needed for transcoding,
> but probably a little less CPU intensive.
>
> _______________________________________________
Thanks for the excellent info Stephen