[mythtv-users] tivo patents cover mythtv?

[Daniel Kristjansson]

On Sat, 2010-03-06 at 13:30 -0500, John Drescher wrote:
> >> 1. A process for the simultaneous storage and play back of multimedia
> >> data, comprising the steps of:
> >> accepting television (TV) broadcast signals, wherein said TV signals are
> >> based on a multitude of standards, including, but not limited to, National
> >> Television Standards Committee (NTSC) broadcast, PAL broadcast, satellite
> >> transmission, DSS, DBS, or ATSC;
> >> tuning said TV signals to a specific program;
> >> providing at least one Input Section, wherein said Input Section converts
> >> said specific program to an Moving Pictures Experts Group (MPEG) formatted
> >> stream for internal transfer and manipulation;
> >
> > Myth doesn't do that.
> >
> 
> This sounds exactly what MythTV does.
> 
> >
> >> providing a Media Switch, wherein said Media Switch parses said MPEG
> >> stream, said MPEG stream is separated into its video and audio components;
> >
> > Myth doesn't do that.
> >
> 
> I would bet MythTV does that internally.

MythTV is file oriented, not stream oriented. Even LiveTV is just a
series of files and the player is just told which files follow and
precede the current file. This gives us the flexibility to use
non-stream oriented formats like NUV, which is still our default
file format and codec when there is no hardware encoding involved.
For MPEG it's a real PITA because we need to store the keyframe
map (we do it in the DB) to emulate a container like NUV. But it
also means internally MythTV is just a programmable VCR, it doesn't
care if you are recording to a hard-drive, tape, or to the "cloud",
just so long as the storage provides a C API. There are downsides
to the MythTV method as well. A TiVo's recording is just a series
of chunks in a stream, so they can have overlapping recordings by
simply recording some of those chunks as belonging to two recordings.
This is akin to hard-linking, the overlap chunks are not deleted
until both recordings are deleted. While for MythTV to support such
a feature we would need to simultaneously encode two files which
doubles the load on the CPU and requires the file system to not
only be able write twice as fast but also in the case of a hard
drive seek between the two files on disk between writes. No one
writing a TiVo style appliance with hard-disks would want to emulate
the MythTV model. Our model is more suited to SSD's and you will
often hear old hands at MythTV recommend at least two hard-drives,
one for /var and another for recordings. But while our model is
ill suited for a single hard-drive system it is well suited for
much larger systems composed of multiple backends and frontends
since it doesn't make the assumption that you are using a hard
disk for storage like the TiVo system does.

Parts of the TiVo system are also covered by GPLv2, so we probably
could incorporate those parts of code and system if we wanted to,
but the design is so radically different that to try to turn MythTV
into a TiVo or vice versa would require a complete rewrite and an
incredible number of man hours.

-- Daniel