[mythtv] bttv recordings run fast
andrewmahone at eml.cc
Sun Mar 7 02:24:44 EST 2004
On Saturday 06 March 2004 15:18, Bruce Markey wrote:
> Therefore, I use these on my Low Quality
> settings where there is plenty of CPU time available and I see
> a significant improvement. I think many people use these for
> their highest quality settings assuming that they want the 'best'
> picture possible but it doesn't really do any good and just
> burns cycles.
HQ and 4MV will help if bitrate is low, they'll squeeze a little bit more
quality out of the codec and reduce the blockiness. If you're using very,
very high bitrates because you're concerned about quality, turning these on
will probably not improve things much, and if it overloads your CPU and
causes frame drops, will probably make things worse.
What I was saying was not that these options are no help at all, but that
there are others, not currently exposed in MythTV, that work better. And
yes, people do seem to expect these options to improve color reproduction,
which AFAIK they will have a negligible effect on, if any.
> I'm curious what differences you see, if any, when using these
> modified settings? I've tinkered with the v4l tuner settings,
> XV controls and TV controls for over a year trying to get the
> image to look more like the original cable TV image.
I'll try your settings. When I say that default picture controls + default
adjust filter looks fine, please understand that I haven't compared them to
the cable connected directly to my TV. Without adjust, at default picture
controls, MythTV video is badly washed out, and adjust gets me to the point
of having nothing glaringly wrong - if there are variations, they're
transparent. When I'm not as busy playing with my new Rio Karma, I'll try
switching back and forth to see if I can see the difference.
> The timestamps also get funky when the CPU is pegged. There is
> a thread that grabs the frames from the card and marks the
> timecode based on the current system time. When the system isn't
> busy frames are about 33msec apart. If the CPU is pegged the
> grabber thread may not get to grab the frame until later and
> the current system time no longer reflects the spacing. One
> frame may be marked 100msec after the previous frame followed
> by intervals like 4msec and 12msec etc.
Hrm, I can see how that could be a problem. Does the v4l API provide any
method for detecting dropped frames? If it does, you could base timecodes on
the known interval between frames for the used TV standard, and multiply them
appropriately when frames are dropped.
> Maybe you could test with it spewing out time stamps at key
> points to see where the differences are.
Now why didn't I think of that? :-) It will take a bit of work to make this
not have a large impact on how the code runs, but this might be a big help...
The other thing I'm working on is a tweak for filter benchmarking that reports
best, worst, and a moving average of per-frame times, rather than reporting
the average over each interval, as is currently done.
> Last week I was benchmarking the the new scheduler (which is
> quantifibly oodles faster BTW =). Typical schedules would run
> in one or two kernel scheduler time slices and the timestamps
> weren't significant enough to make valid comparisons. Therefore
> I had to do some terribly complex schedules adding hundreds of
> shows to force it to take a half second to second in order to
> get numbers that were worth comparing.
Wow, that's *sweet*. I haven't fiddled with my schedule recently, but there
used to be a very obvious delay for some things, especially for the conflicts
page to update after changes. If this is improved, I need to give a big
thanks to the people hacking on the scheduler :-)
andrewmahone AT eml DOT cc
More information about the mythtv-dev