[mythtv-users] No more choppy video -- problem (mostly) solved!

[Jason Tackaberry]

Thought I'd follow up and post my discoveries to this list, so that
others might benefit.

First, many thanks to Ray Olszewski (thanks, Ray!) who took the time to
compose a long, insightful reply to my call for help.  His
recommendation to use VirtualDub (actually, I used avidemux
[http://avidemux.sf.net], which is similar and runs on Linux) to step
through the video frame-by-frame was most useful.

To recap, my problem was that I was seeing jerkiness, and some
stuttering when capturing from my tuner card and playing back.  My tests
were done using mencoder/mplayer and I was using a RAM disk to eliminate
any issues due to slow harddisk.  My initial assessment was that the
capturing was the problem, not the playback.  In fact, the problem was
in both steps.

I tuned to CNN and used the scrolling news marquee, which served as a
very good metric of any jerky video.  It's worth noting that on other
channels without that sort of continual panning, by and large I did not
notice much jerky video.  I'd also like to express my frustration at the
number of commercials on CNN.  The amount of advertising on that channel
is utterly mindboggling. :)

After doing a frame-by-frame examination of the video stream, I
discovered a slight jump in the scrolling text after every 30 frames. 
And indeed, that's because mplayer, for whatever reason, was capturing
at 29 fps, and not 29.97 fps.  I assume that's the frame rate the bttv
driver told it to use, but I have no idea why.  By forcing mencoder to
capture at 29.97, that problem was solved.  I need to find out of MythTV
is also capturing at 29fps, but I'll look into that after.

When playing back the "new and improved" captured video, I discovered it
was _still_ jittery and choppy.  At first I thought it might have to do
with the timestamps on each frame in the AVI, but I noticed that the new
stuttering was happening in random places.  And if I'd replay a part
that just stuttered, it might play smoothly that time.

I was nowhere near maxed CPU-wise, so my hunch was that it had to do
with scheduling.  A friend of mine suggested, since I was using the O(1)
patch, that I give mplayer realtime scheduling.  So, I fetched schedtool
(searched freshmeat) and gave mplayer SCHED_RR with priority 50.  It did
seem to help a little bit, but not completely.  Playback was exhibiting
the same symptoms.

In my experimentation, I tried -vo gl2 with mplayer, and noticed it was
playing back smoothly.  I _also_ noticed that X wasn't using any (well,
much; it wasn't showing up on top(1)) cpu time that way.  And indeed,
with -vo xv, X would use about 20% CPU.  So, I gave X SCHED_RR, and
playback suddenly became smooth!

So, this was actually a combination of two problems.  Let me recap:

Problem 1: Jerky encoded video.
Solution: mencoder was only encoding at 29fps.  Force mencoder to encode
at 29.97 frames (-tv fps=29.97)

Problem 2: Jerky playback
Solution: mplayer and X weren't getting the cycles when they needed
them.  Give mplayer and X processes real-time scheduling (SCHED_RR) at a
high priority.

For those interested, here are some of the commands I used:

1. Capture video with mencoder (raw video from Composite1, raw audio
from line-in on soundcard):

	mencoder -tv on:driver=v4l:device=/dev/video0:norm=NTSC:input=1:width=640:height=480:adevice=/dev/dsp:forceaudio:forcechan=2:fps=29.97 -oac copy  -ovc copy -o test.avi

2. Same as above, except compress video with mjpeg:

	mencoder -tv on:driver=v4l:device=/dev/video0:norm=NTSC:input=1:width=640:height=480:adevice=/dev/dsp:forceaudio:forcechan=2:fps=29.97 -oac copy  -ovc lavc -lavcopts vcodec=mjpeg:vhq:vqscale=2  -o test.avi

3. Using schedtool to give real-time scheduling to a pid, say 10150:

	schedtool -2 -p 50 10150

Some notes on the above.  I have no idea if a static priority of 50 is
appropriate.  But given a range of 1-99, 50 seemed like a good enough
cohice to me.  Second, capturing raw video required writing to ramdisk,
since my harddisk wasn't fast enough to keep up with the volume of
data.  Encoding the video with mjpeg worked just fine when writing to
disk and video was not jerky.

While setting SCHED_RR on X and mplayer makes playback smooth, it does
fairly nasty things when you want to capture and playback at the same
time, even if both the encoding and playback processes are running at
the same static priority.  So while this approach would work to smoothen
playback if your backend/frontend are on different machines, it doesn't
look like it's a very good idea to do this if they're on the same
machine.  

Setting X and the player to a higher priority with nice seems to be a
good compromise.  I do notice an improvement this way, although it's not
quite as smooth as with SCHED_RR.  Obviously. :)

Thanks to those who replied to my initial email.

Cheers,
Jason.

-- 
Jason Tackaberry  ::  tack at auc.ca  :: 705-949-2301 x330 
Academic Computing Support Specialist
Information Technology Services
Algoma University College  ::  www.auc.ca