[mythtv-users] MHEG issues (UK) - flickering, video resizing, mind the gaps!
samlists at ijacobs.co.uk
Tue Apr 8 13:40:16 UTC 2008
On Tue, Apr 8, 2008 at 1:21 PM, Mark Kendall <mark.kendall at gmail.com> wrote:
> On 06/04/2008, Sam Jacobs <samlists at ijacobs.co.uk> wrote:
> > 2. When an app requests video to be rendered quarter-screen, the
> > frontend actually decodes and renders a copy of the same video stream
> > (CPU usage about doubles, but network activity stays the same). While
> > this probably isn't an issue on reasonably powerful frontends with SD
> > video (on my Mac, CPU usage is about 40% normally, and 80% when on a
> > BBCi page displaying 1/4-screen), it isn't very efficient and I'd
> > imagine things would suffer greatly with HD video.
> The frontend does not decode the stream twice (although it might look like it!).
It certainly does look like it, especially taking into account the
doubled CPU usage. I can't code though (took me about an hour to find
where the MHEG font is defined in the source), so it's entirely likely
that I'm totally wrong!
> When you're using straight XVideo as the renderer, the video frame is
> the only thing that is displayed on the screen. The osd, PiP etc are
> all blended into the frame in software before it is displayed. The
> MHEG screens are also rendered as an OSD (and hence are blended into
> the frame) and when the video stream is shown half/quarter size etc,
> it is done using very similar code to that used to render the PiP -
> the frame is scaled to a given size and blended into 'itself'. You
> could clear the rest of the video information but if the MHEG 'osd'
> is rendered correctly then it is unnecessary.
As I'm on Mac OS X, quartz is being used as the renderer, but I think
it does use softblend for the OSD stuff. What *really* confuses me is
that the text looks so crappy in the screenies - it's not nearly as
beautiful as Tiresias when it's rendered in the menus, but it's not as
bad as the screenshots would have you think.
> > 3. The gaps! Obviously, it must be difficult to get everything laid
> > out correctly, and the engine does a great job at the moment, but
> > because of 2 the gaps are really obvious because the fullscreen video
> > shows through them!
> From the screenshots, this looks like a regression in the code as this
> was originally fixed when MHEG was first added to svn (2-3 years ago
> now). The original problem was due to the osd code moving rendered
> elements by one pixel - which was all related to the YUV12 video
It doesn't look like that's the only possible regression in that area
- when tuning to a channel that's off-air, or a radio channel, or
trying to use the BBCi news multiscreen, etc., the frontend crashes.
When I looked it up, the bug tracker and the mailing list gave me the
impression that it was fixed. I don't have the confidence to annoy the
devs by re-opening bugs that could very well be unrelated in terms of
> If I get a chance, I'll have a look at it but I may need some test
> clips as I'm no longer UK based.
That could be arranged - as much as I *hate* my current ISP, it is at
least 2Mbit/s symmetric, more or less.
> mythtv-users mailing list
> mythtv-users at mythtv.org
Sam Jacobs on MythTV 0.21, UK Freeview, EIT-only EPG
mythbox: BE+FE, Mythbuntu 8.04, Athlon XP2000+ at 1.6GHz, 512MB RAM,
nVidia GeForce 4MX (proprietary driver)
tuners on mythbox: Nebula DigiTV PCI, Elgato EyeTV for DTT Stick
(Hauppauge Nova-T USB Stick in disguise!)
smbx: FE, Mac OS X 10.5 Leopard, Macbook Intel Core Duo at 2.0GHz, 2GB RAM
More information about the mythtv-users