[mythtv] record/playback bug
myth at zendo.net
Thu Mar 13 09:29:08 EST 2003
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.
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.
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.
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?
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%.
On Thu, Mar 13, 2003 at 12:34:47AM -0800, Bruce Markey wrote:
> > 1 width 640
> > 1 mpeg4bitrate 2211
> > 1 mpeg4minquality 5
> 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:
> 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
More information about the mythtv-dev