On 6/6/2017 6:39 PM, faginbagin wrote: > Yep, I've still got a few old laptops that have been working quite well
> as frontends. But one isn't performing quite as well with mythtv 0.28
> and mythbuntu 16.04 as it is with mythtv 0.27 and mythbuntu 12.04. So,
> I'm trying to understand why, and whether there's anything I can do to
> get it to perform running 0.28 as well as it does running 0.27. The
> laptop and the master backend have multiple boot partitions, so that's
> how I switch back and forth between 0.27 and 0.28
> I see slight but noticeable stuttering during panning scenes when I
> playback standard definition H.264 video on 0.28 but not when I play
> back the same video on 0.27. It's not CPU bound, the CPU hovers around
> 30% to 35% on both versions and might be using a tad less CPU on 0.28 as
> it does on 0.27.
> The laptop is a Dell Inspiron B130 with an Intel Celeron M 1.5 GHz CPU
> and an Intel Mobile 915GM/GMS/910GML Express Graphics Controller. The
> display is 1280x800 resolution. It's configured to use the Slim playback
> profile on both 0.27 and 0.28, as defined in the database migrated from
> 0.27 to 0.28.
> I have compared mythfrontend logs using -v general,playback at the
> default info level. I can see no meaningful difference in the log
> output. I've hesitated to try the debug level, for fear that might push
> the CPU and/or disk to work too hard, although maybe that should be my
> next step?
> I have compared Xorg.0.log on both OSs, and only see slight differences
> like version numbers, and a handful of different messages that I suspect
> are due to logging changes in source and not meaningful.
> FWIW, the laptop can play 720p and 1080i MPEG2 transport streams
> smoothly in both 0.27 and 0.28. But it cannot play high definition H.264
> content on either, where it's definitely CPU bound. I've also got a
> couple of circa 2004 thinkpads with Pentium M CPUs and Radeon GPUs that
> CAN handle the SD H.264 in both 0.27 and 0.28 environments. It's just
> this Dell that's keeping me from cutting over to 0.28.
> Has anyone else noticed a degradation in performance on older hardware
> after upgrading?
> Any suggestions on how to identify the cause, e.g. OS module, X driver
> or mythtv?
This is my follow up to everyone who offered suggestions on getting my
old laptop to function on 0.28/16.04 at least as well as it did on
0.27/12.04. First a summary, then the gory details.
I could not find a configuration that would allow 0.28 mythfrontend to
work as well as 0.27 mythfrontend playing standard definition h264
video. I think there's strong evidence that the problem is due to
something that changed in the mythfrontend or libmyth* code, not in the
OS, Xorg, or ffmpeg code that mythtv syncs with.
I found that mythtv 0.27 on mythbuntu 14.04 works as well as it did on
12.04. So, in order to get security updates for a couple more years, I
am upgrading all my machines running 12.04 to 14.04. Maybe this laptop
will give up the ghost before I get new hardware that really needs a
newer OS, Xorg or version of mythtv. Or I may set up a cross compile
environment on another machine so I can do a git bisect and identify an
offending commit. The laptop is too slow and doesn't have enough disk
space to do that.
Mike Perkins suggestions:
* Check wiki articles:
(Seconded by Anthony Giggens)
Not sure this article can help since I'm using the laptop's built in
display. xrandr reports:
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis)
331mm x 207mm
800x600 60.3 56.2
VGA1 disconnected (normal left inverted right x axis y axis)
TV1 disconnected (normal left inverted right x axis y axis)
As you can see, not much variation in refresh rates.
Gave it a try after RTC timer didn't help. Found that aspect ratios are
messed up and all video is pillar boxed. As you can see from the above
xrandr output, the display's native resolution is 1280x800, with an
aspect ratio of 16x10, but the alternate supported resolutions are all
4x3. I tried tinkering with aspect ratios during playback but could not
find anything sane, or any way to use the full width of the display.
The laptop was using usleep in both 0.27 and 0.28. Getting RTC to work
sounded promising. I was really hoping this would do it, but it had no
effect. Tried both 1024 and 2048 for max_user_freq. It's hard to see
that going higher would help.
* Cut mythtv out, compare playback with vlc on 12.04 vs 16.04
If RTC doesn't help, this might provide more diagnostic info.
Played the troublesome SD h264 mp4 file on vlc. Looks fine on 16.04 with
vlc 2.2.2 and CPU is comparable to mythfrontend (see below). That's
using XVideo/xcb_xv video output, which I believe is comparable to
mythfrontend's Slim profile. Also tried OpenGL GLX/xcb_glx video output,
and found the CPU usage was about double the usage with XVideo output.
Also looks fine on 14.04 with vlc 2.1.6 (I had replaced 12.04 by this
time). Similar results WRT CPU usage, maybe 3-5 points lower. This seems
to suggest the problem is changes from 0.27 to 0.28 in mythfrontend.
Also suggests a possible workaround by configuring mythfrontend to use
vlc to playback h264 content.
* Try a "complex" transcode on the local test file using ffmpeg on
both 12.04 and 16.04 to see if that shows a significant difference or
not (something to make the laptop sweat / work hard so small differences
might be more readily noticed).
I think the idea is to compare how fast the laptop can decode the video
in 12.04 vs 16.04. Using mythffmpeg in both environments might provide
some insight into changes from 0.27 to 0.28 in the slim playback
profile's performance, since both mythffmpeg and mythfrontend use the
same code. Between this and comparing playback with vlc, it could
identify whether the problem is in mythtv or the O/S and/or Xorg
drivers. I decided to use mythffplay, since the problem is one of
decoding and display, not transcoding.
0.27/14.04, based on ffplay/ffmpeg 1.2.7. Works well, CPU is comparable
to mythfrontend with Slim profile.
0.28/16.04, based on ffplay/ffmpeg 3.0. Works well, CPU is comparable to
mythfrontend with Slim profile.
I think this is even stronger evidence than the vlc test that the
problem is not in the OS, Xorg, drivers, or in the port of ffmpeg to
mythtv, and narrows it down to the mythfrontend or libmyth* code that
Try mythbuntu 14.04. It won't get me to mythtv 0.28, but it will give me
a couple more years of long term support and security updates from
Ubuntu. Seems to work as well as 12.04 and eliminates 2 years of OS and
Xorg changes as possible culprits. Only drawback is a slight increase in
memory usage, see stats for frames decoded/free suggestion.
Peter Bennett suggestions:
- Try an OpenGL playback profile. This is easy to test.
On 12.04 tried glxgears, it reported an average around 15fps, well below
the display's 60Hz refresh rate.
On 16.04 tried glxgears, it reported an average around 48fps, much
closer to the display's 60Hz refresh rate.
On 0.28/16.04 using "OpenGL Slim" playback profile pushes CPU usage up
about 15 percentage points. That's OK for the troublesome SD h264 video,
which plays more smoothly at around 50%. But HD mpeg2 content that plays
OK with the Slim profile, using 80-90% CPU, is now CPU bound and
stutters badly, much worse than the slight stuttering it fixes for SD
h264 video. That's true for both 720p and 1080i with the default One
Field deinterlacer as well as deinterlacing set to None. So using an
OpenGL profile fixes an annoying problem with one type of content but
creates more serious problems for other content.
- Could be https://code.mythtv.org/trac/ticket/12907
This ticket talks about problems playing 60fps video. It doesn't say
what encoding or resolution. The laptop can play 720p mpeg2 60fps video
running 0.28/16.04. My problem is with h264 encoding, standard
definition resolution, with an average frame rate less than 25fps.
Stuart Auchterlonie suggestion:
Monitor playback OSD frames decoded/free figures, should stay as high as
possible. I had used this to monitor CPU usage, but not frames decoded/free.
0.27/12.04 slim - consistently 28/1, and CPU approx 30-40%, briefly up
to 43% during panning.
top stats mythfrontend mem 14.8% Xorg 2.4%
0.27/14.04 slim - consistently 28/1, and CPU approx 30-40%, briefly up
to 43% during panning.
top stats mythfrontend mem 15.4% Xorg 2.6%
0.28/16.04 slim - consistently 28/1, CPU similar to 0.27/12.04.
top stats mythfrontend mem 23.5% Xorg 3.3%
0.28/16.04 opengl - consistently 28/1, CPU increased to around 50%
top stats mythfrontend mem 23.2% Xorg 2.0%
Brian Murrel suggestion:
Replace mythfrontend with Kodi.
I think this would involve a steep learning curve, not just for me, but
for my family. I would consider this a last choice.
Again, many thanks for everyone's suggestions. I welcome any other
ideas, thoughts, etc.
mythtv-users mailing list
firstname.lastname@example.org http://lists.mythtv.org/mailman/listinfo/mythtv-users http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org