I have archived a bunch of kiddie shows off to .m4v files using HandBrake. It seems that if I attempt to play back anything that was encoded with v0.9.3 or later, the video/audio will stutter to the point of being unwatchable, and the mythfrontend.log file complains about waiting for video buffers:

Code:
2011-01-30 14:49:20.740 Received a remote 'Clear Cache' request
2011-01-30 14:49:26.492 MythVideo::ScanVideoDirectory Scanning Group (myth://Videos@Mythbox/myth/video/)
2011-01-30 14:49:37.375 TV: Attempting to change from None to WatchingVideo
2011-01-30 14:49:44.311 AFD Warning: ScanATSCCaptionStreams() called with no PMT
2011-01-30 14:49:44.312 AFD: Opened codec 0x7fdaac0c7690, id(H264) type(Video)
2011-01-30 14:49:44.323 AFD: codec AAC has 2 channels
2011-01-30 14:49:44.326 AFD: Opened codec 0x7fdaac07a6a0, id(AAC) type(Audio)
2011-01-30 14:49:44.327 AFD Error: Could not find decoder for codec (Unknown Codec ID), ignoring.
2011-01-30 14:49:44.434 AO: Opening audio device 'default:CARD=NVidia' ch 2(2) sr 48000 sf signed 32 bit reenc 0
2011-01-30 14:49:44.439 AudioPlayer: Enabling Audio
2011-01-30 14:49:44.807 VDPAU: Created 2 output surfaces.
2011-01-30 14:49:44.807 VDPAU: Version 1
2011-01-30 14:49:44.808 VDPAU: Information NVIDIA VDPAU Driver Shared Library  260.19.06  Mon Sep 13 04:58:44 PDT 2010
2011-01-30 14:49:44.808 VDPAU: Created VDPAU render device 1280x720
2011-01-30 14:49:45.016 Player(0): Forcing decode extra audio option on (Video method requires it).
2011-01-30 14:49:45.062 Player(0): Video timing method: USleep with busy wait
2011-01-30 14:49:45.062 TV: Changing from None to WatchingVideo
2011-01-30 14:49:45.081 VDPAU: Added 2 output surfaces (total 4, max 4)
2011-01-30 14:49:48.093 Player(0): Waited 100ms for video buffers AAAAAAAAAAAAAaaaa
....   much of the same (100ms errors) clipped ....
2011-01-30 14:49:53.410 Player(0): Waited 100ms for video buffers AAAAaaaaAAAAAAAAA
2011-01-30 14:49:53.694 TV: Attempting to change from WatchingVideo to None
2011-01-30 14:49:53.859 VDPAU Painter: Clearing VDPAU painter cache.
2011-01-30 14:49:53.859 MythPainter: 2 images not yet de-allocated.
2011-01-30 14:49:53.987 TV: Changing from WatchingVideo to None
Seems to have started shortly after I installed 0.24 from scratch on a new (bigger) HD. I never had this issue on using 0.24 off the old HD (I had gotten to 0.24 and 10.10 via updates on the old HD. Rather than trying to clone the old system, I simply installed 10.10/0.24 from scratch and moved my recordings, archive files, and database).

I've been finding here and there others reporting errors with this same 100ms tag ex: http://code.mythtv.org/trac/ticket/9511 but that would seem to apply to live TV, and not M4V file playback. Yes - m4v format because the kids (2 and 4) can work my iPod Touch...

My config: combined FE/BE system, NVIDA 8200 IGP, using VPDAU Slim profile (didn't help when I tried Normal or CPU--)

I downloaded the most recent 0.24 release today (30012011):
Code:
MythTV Version   : v0.24-133-g06c8142
MythTV Branch    : fixes/0.24
Network Protocol : 63
Library API      : 0.24.20101129-1
QT Version       : 4.7.0
Options compiled in:
 linux debug using_alsa using_jack using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg
Spending far too long for my wife's sanity attempting to diagnose one night, I found the following characteristics.
1) files play splendidly via vlc or mplayer - my issue seems to be confined to the MythTV internal player

2) if I elected NOT to use Storage Groups, and instead set up the filename directly in the FE, it seemed to play back fine. I did this because when I was attempting to set up an alternate player within MythTV, I noticed that %s resulted in a pseudo URL: something like mythtv://Videos@MyMythBox/abbreviated/pathname/filename, and I wondered if Myth is attempting to get to the file via a network connection. note, an "ifconfig" gives
Code:
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6883476 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6883476 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:72164314460 (72.1 GB)  TX bytes:72164314460 (72.1 GB)
Why would I get such a HUGE amount of data transferred through the loopback?

3) if I pass the offending files through ffmpeg (-vcodec copy -acodec copy), things seem to get better. The stuttering doesn't disappear completely, but reduces to once in a while as opposed to unwatchable. The output from HandBrake -i on both versions:
Good File (after ffmpeg passthrough):
Metadata:
major_brand : M4V
minor_version : 512
compatible_brands: isomiso2avc1
encoder : Lavf52.64.2

Bad File:
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42isom
encoder : HandBrake 0.9.3 2008112300

4) if I encode a video from scratch, using HandBrake v0.9.5, it seems to work just fine:
New encode:
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42isomavc1
encoder : HandBrake 0.9.5 2011010300

What is the significance of mp42isom versus mp42isomavc1?



Can anyone point me in a good direction? I saw a brief mention in the release notes for 0.24-fixes that there was a 100ms issue addressed about Dec-17-2010, and had hoped that that fix would be wrapped into the latest Mythbuntu release (again, I downloaded the latest today), but it hasn't seemed to hit yet, or at least what may have been addressed may not be what's affecting me.

Thanks
John Latz