[mythtv] record/playback bug

[Bruce Markey]

Eli Criffield wrote:
> Yep setting it to those settings did the trick. Thanks for the great
> explanation of whats going on, this should be added to the FAQ for anyone
> else getting fast video playback, the OSD time is off, or lost the ability to
> rewind or fast forward acutely goes back-wards.

This is kind of what section 18.4 "What capture resolution
should I use?" is for but we didn't know about these specific
symptoms...

> With the settings suggested the cpu usage of mythbackend hovers around 60%
> to 70%. The pixelation is pretty noticeable but the motion is a lot smother.
> It seems it should be possible to get a picture with out noticeable
> pixelation and smooth motion and not drop frames on an Athlon-xp 1600, I'll
> try different settings tonight and see what i can come up with.

Increasing the bitrate will reduce pixelation at the expense
of disk space.

> Is there some way to add an error message when it can't drop frames fast
> enough to keep putting 30frames/sec in the file? That would be useful.

There are a few things to consider for 0.9. Right now, I'm
just happy this is a configuration/documentation issue and
not a 'stop ship' bug ;-).

> I now have good understanding of different resolutions and how much cpu
> should be free.
> 
> I still don't quite understand how the min quality and the maximum quality
> and the bit-rate work together. Is the bit-rate variable at all or does the
> bit-rate setting absolutely define your file size for a giving time. If it is
> absolute shouldn't that combined with your resolution define the quality?

I agree with Matt that these should be left alone unless
you really know the problem that you are seeing and the right
solution.

> How does the encoder decide what quality to use between the min and the
> maximum? It doesn't appear to be cpu related otherwise it would use as many
> cycles as it could, thus having a higher cpu usage then 60%.

There are periodic full key frames followed by frames that
just account for the difference from the previous frame. The
more motion, the more bits to change. If there is little change,
the changes are encoded and it's done. If there is a lot of
change, it cheats to fit the changes in the target bitrate.
So, the encoder doesn't decide per se, it's a result of what
needs to be done. If the bitrate is higher, the average quality
rating will be higher but there is the law of diminishing
returns and you waste more disk space. The quality parameters
impose limits on some border cases but moving these limits to
affect typical cases is bad. Use the defaults.

The CPU usage is most affected by how many total pixels it
has to work on so changing the resolution will have the
biggest effect on CPU time.

--  bjm