[mythtv] record/playback bug

[Bruce Markey]

Eli Criffield wrote:
...
> model name      : AMD Athlon(tm) XP 1600+
> stepping        : 2
> cpu MHz         : 1406.805
> cache size      : 256 KB
...
> 1       width   640
------------------^^^

> 1       height  480
> 1       rtjpegquality   170
> 1       rtjpeglumafilter        0
> 1       rtjpegchromafilter      0
> 1       mpeg4bitrate    2211
--------------------------^^^^

> 1       mpeg4maxquality 2
> 1       mpeg4minquality 5
-------------------------^^^

> 1       mpeg4qualdiff   3
> 1       mpeg4scalebitrate       1

Please try changing your recording parameters to width 544,
bitrate to 3300 and Minimum Quality to 15. Record a show
without watching a show at the same time or running any
other CPU intensive tasks (compiler, games, SETI, whatever).
If possible, please run "top" in a terminal window while
it is recording and watch the "CPU states: ... % idle".
This should be at least 10% throughout the recording. If
so, your recordings should be okay.

Here's the problem. The recordings should have 29.97 frames
per second. For each frame there is an audio time code to
mark the time it was recorded so that the audio can be
played back at the original speed. At about 30 frames per
second, when the time codes hit 60 sec, the frame number
should be about 1800 (30 x 60). This is true for files
that recorded correctly.

In your "Monster Garage" file, when the timecode hit 60 sec
it is on frame number 711(!). This means that only an
average of about 12 per 30 frames were written to the file.
In the playback preview with no audio, the video frames
are simply played 30 per second and so it runs about 3X
fast forward. When you or I play the file with audio, it
wants to adjust the timing to match 30 frames per sec to the
timecodes. But there are only an average of 12 frames so
there is a constant tug of war to compromise when to play
the next frame. The video is too fast, the audio is clipped,
the buffer overflows, and it just goes whacky. Further,
the X server and mythfrontend use a lot more CPU while this
battle rages.

I was able to make my own files like this by using a 1.2GHz
Athlon system with two tuners and recording 2 @ 720x480. I
get files just like Monster Garage and even a little worse
at about 600 frames per minute.

If the CPU is a little too busy, it should "drop" a frame
by copying the previous frame so there is no new compression
work to do. However, if the workload is way too much, it
simply doesn't write enough frames to the file fast enough.

I saw that Monster Garage was recorded 640x480 and thought
that maybe you were using a favorite old "legacy" system
and estimated it might be about 600MHz.

Not so. At 1406.805 MHz you should be able to easily do
one 640x480 recording. However, I see that you raised the
MinQuality but left the bitrate low. I tried several tests
and found that you can get low frame rates with a raised min
quality and and low bitrate but it is not as significant
as overworking the CPU. I think the reason is that if it
isn't allowed to compress too much but is asked to fit
all the motion in a limited number of bits, it fails to
'put ten pounds in a five pound bag' and doesn't manage
to write all the frames in time.

You mentioned that The Simpsons did better than other
shows. This makes sense. Cartoons have large areas of
a single color that are easy to compress.

So, take a minute read and understand:

http://www.mythtv.org/docs/mythtv-HOWTO-18.html#ss18.4

Fire up top and experiment a little.

Raise your bitrate and loosen the min quality for now
to be sure that this isn't contributing to the problem.

Lower the recording width so that there isn't as much
workload. It should still look about as good, maybe even
better if the bitrate is higher. Certainly better if it
prevents the playback from going whacky ;-).

Watch top during recording. If there is less 10% idle CPU
time (like 0% ;-). see if there are processes other than
two "mythbackend" that are using significant CPU time. If
you playback during recording, notice if "mythfrontend"
takes more CPU time on damaged files than on good ones.

--  bjm