[mythtv-users] Arm Based Frontend

HP-mini blm-ubunet at slingshot.co.nz
Thu Apr 24 09:56:34 UTC 2014


On Wed, 2014-04-23 at 20:04 -0400, Timothy Krantz wrote:
> > -----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:
> > 
> > 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
> 
The idea with experimenting with de-interlacing options was just that..
VDPAU API does not allow for decode only, but (afaik) it does allow for
de-interlace & presentation only.

Does your experience so far suggest that de-interlacing is functional on
this h/w?
Because that is quite some discovery..




More information about the mythtv-users mailing list