[mythtv] Understanding the myth source code

[Raymond Wagner]

On 5/25/2010 16:38, James Courtier-Dutton wrote:
> When recording a program, why is the mythbackend trying to decode
> audio and video streams?
> Why does it need to decode them?
>    

A modern compressed video is composed of a sequence of key frames, 
separated by a number of frames based off each other and the previous 
keyframe.  The keyframe is complete in and of itself, so in order to get 
a complete image, you must start playback at the keyframe.  When you 
want to seek to a point in a file, you need to find the nearest 
keyframe, and decode forward to the point you want.  This process is 
largely guess work.  A video player knows the average bitrate, so it 
makes an estimate at which byte-location in the file the nearest 
keyframe.  It finds a timecode, takes another guess, and continues this 
process until it finds the keyframe it wants.
Rather than have to screw around with this while streaming content over 
the network, MythTV simply records the byte-location of these keyframes 
as it is capturing the video.  It's not doing a full decode, it's merely 
processing the field order.  That way, the frontend can simply jump 
straight to the desired location, rather than having to perform that 
trial-and-error search.

> Also, if the backend has to wait for a key frame before sending the
> stream to the frontend, won't this just increase the time it takes to
> switch channels?
>    

What good would it do to try to start playback before getting that first 
keyframe?  All you could display is a bunch of meaningless garbage.  
There is no way around that.  You shouldn't expect more than a second or 
so between keyframes.  Most of my digital recordings seem to be around 
half a second apart.

> I would like to improve the time it takes to switch channels, but
> would like to be sure I have the reason why correct before spending
> time on it.
>    

As a consequence to MythTV's networked behavior, it will add somewhere 
between 1-2 seconds of latency from when it starts recording, to when 
the frontend gets the video.  Analog tuners may take up to a second 
before they lock a channel.  MPEG encoder cards may take an additional 
second before they start sending data to the computer.  Digital tuners 
may take several seconds to tune a multiplex, additional time to find 
the proper stream, and still more to wait for a keyframe.  Some set top 
boxes have been known to take 5-10 seconds before they start sending 
anything.  It all boils down to DVRs in general (not just MythTV) being 
less than ideal for channel surfing.