[mythtv-users] Arm Based Frontend

[Timothy Krantz]

> -----Original Message-----
> From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-
> bounces at mythtv.org] On Behalf Of Raymond Wagner
> Sent: Wednesday, April 23, 2014 7:35 PM
> To: Discussion about MythTV
> Subject: Re: [mythtv-users] Arm Based Frontend
> 
> On 4/23/2014 5:27 PM, HP-mini wrote:
> > On Wed, 2014-04-23 at 16:08 -0400, Timothy Krantz wrote:
> >>> -----Original Message-----
> >>> From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-
> >>> bounces at mythtv.org] On Behalf Of HP-mini
> >>> Sent: Wednesday, April 23, 2014 3:45 PM
> >>> To: mythtv-users at mythtv.org
> >>> Subject: Re: [mythtv-users] Arm Based Frontend
> >>>
> >>> On Tue, 2014-04-22 at 19:09 -0400, Timothy Krantz wrote:
> >>>
> >>>> Well I can now confirm similar results on the MK802 compared to the
> >>>> hackberry.
> >>>>
> >>>> Video looks pretty good, audio is ok.  It just tries to playback
> >>>> too
> >> fast.
> >>>> I think it is reporting FPS varying from 36-42.  Again, basically
> >>>> the same as the hackberry. I really think this would be a nice 5
> >>>> watt front end if I could figure out how to get it to play back at
30ish
> FPS.
> >>>>
> >>>> Tim
> >>> What happens when you enable de-interlacing?
> >>> This h/w might cope with the most basic option (one field?).
> >>>
> >>> What happen if you set the default video mode to interlaced i60
> >>> output &
> >> let
> >>> the TV de-interlace?
> >>>
> >> I'm going to confess ignorance here.  How would this *slow down* the
> >> playback?
> >>
> >> Tim
> >>
> > There is a small possibility that the video speed is due to the video
> > being interlaced & s/w bug. De-interlacing doubles the frame rate.
> > Outputting i60/i50 interlaced could move the processor intensive
> > process to the idle TV video processor & might work-around the speed up.
> 
> Since VDPAU decoding is done inside the GPU's video processor, any
> sensible de-interlacing process would be done on the GPU as well, rather
> than pulling the decoded video out of the GPU, deinterlacing, and feeding
> the video back into the GPU for further processing and output.
> MythTV expects VDPAU to be implemented in this manner, and does not
> even support the option of performing CPU deinterlacing. Assuming this
> VDPAU implementation has any support for deinterlacing, it would be doing
> it in the GPU, rather than internally performing those operations on the
CPU.

Thanks for the clarification.  I do find that the picture is by far the best
with VDPAU High Quality as the playback profile.  And all indications are
that is indeed being done by the GPU.

My current suspicion is that the lack of the VBLANK ioctl in the VDPAU
implementation is responsible for the "too fast" playback.  I have seen it
use both the usleep and the RTC methods and both result in it being too
fast.

Tim