[mythtv] Understanding the myth source code

[James Courtier-Dutton]

On 25 May 2010 22:04, Raymond Wagner <raymond at wagnerrp.com> wrote:
> 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.
>

Just so you know, I have extensive knowledge of mpeg and dvb technologies.

I would like to see the process change a bit.
This is what I am seeing. (Using DVB-S)
1) User selects a channel.
2) Mythtv tries to record the channel (livetv) to the livetv folder.
3) mythtv does not store any packets until it has processed the
headers and found the key frame.
4) mythtv then starts recording from the key frame.
5) Once the key frame is found, it also forwards the stream onto the frontend.

I would like to see the process instead be:
1) User selects a channel.
2) mythtv uses cached information in order to identify the PIDs to
record without any processing of the stream required.
3) mythtv starts recording the needed PIDs direct to the livetv folder.
4) mythtv immediately forwards these PIDs to the frontend together
with an auto generated PAT and PMT at the beginning of the stream.
5) mythtv runs a background task on the saved file to extract the key
frame points etc. and build an index.
6) mythtv continuously monitors the stream in order to ensure that the
cached information regarding which PIDs to record is always up to
date.

In this way, one would not have to wait for the PAT and PMT tables
before one could view the video.
Step (6) is also important, because this would provide for a
"continuous retuning" function, as the DVB-S provider moves programs
between multiplexes.
In DVB-S one does not necessarily have to wait for key I-frames in
order to display an image. One can also use a combination of P-frames.
There are some DVB-S streams that build a full image after very little
time with a number of P-frames, but one has to wait about 10 seconds
before an I-frame comes.
This is why I think leaving the filtering to the frontend is the best
option. The channel switch time could be improved considerably.

Does this new approach seem acceptable?
If so, I will try to get the recording of PIDs without looking for
I-frames bit working first.
We can then start moving towards separating the recording from the
indexing a bit more.

Kind Regards

James