[mythtv-users] MHEG issues (UK) - flickering, video resizing, mind the gaps!

[Sam Jacobs]

Hi,

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
>  format.

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
code.

>  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.

Thanks,
Sam

>  Regards
>
>  Mark
>
>
> _______________________________________________
>  mythtv-users mailing list
>  mythtv-users at mythtv.org
>  http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>



-- 
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