[mythtv] VAAPI rewrite

Tue Sep 4 04:09:44 UTC 2018

On Mon, Sep 03, 2018 at 02:08:48PM -0500, David Engel wrote:
> On Sun, Sep 02, 2018 at 03:56:37PM -0500, David Engel wrote:
> > On Sun, Sep 02, 2018 at 04:13:03PM -0400, Peter Bennett wrote:
> > > VAAPI rewite (VAAPI2) is almost complete.
> > > 
> > > I have implemented the fallback deinterlacer for speedup as is done with the
> > > existing deinterlacers.  Time Stretch is working for vaapi2 as well as it
> > > works for others. I believe there is some problem with the "predict drop"
> > > when your frame rate approaches 2x the screen refresh rate. Playback gets
> > > into  a speedup, slowdown repeating cycle. This also happens with other
> > > deinterlacers in the existing code from before I added the vaapi2, and can
> > > be seen by setting your screen refresh rate to 30 then playing a video at 2x
> > > speedup.
> > > 
> > > The existing code switches to the fallback deinterlacer if playback speed is
> > > less than 0.99 or greater than 1.01. I can understand switching when speed
> > > is greater than 1, but I don't know why it switches to fallback for a
> > > reduced speed. Anybody know why this is and whether I should fix it to only
> > > switch when speed is greater than 1 or maybe when speed is greater than,
> > > say, 1.2 ?
> > 
> > You'd need to ask Daniel Kristjansson or check the git log from when
> > that was added.  My guess is that, at the time, it provided smoother
> > playback.  I'm pretty sure the frame drop prediction hadn't been added
> > yet.
> > 
> > > VAAPI2 is ready for testing if anybody is interested (grab the latest patch
> > > on https://code.mythtv.org/trac/ticket/13311). It still needs some cleanup
> > > of comments, fixing conditional compile so that it will compile correctly
> > > with vaapi2 disabled, and testing on other environments (raspberry pi,
> > > shield, vdpau).
> > 
> > Building now.  Will try to test later tonight.  If not then, then
> > tomorrow.
> 
> Nice work, Peter.  I've noticed a couple of things others haven't
> reported yet.
> 
> First, all of the VA deinterlacers are enabled in the OSD.  I thought
> when the post processing was added VAAPI that not all deinterlacers
> were supported on all hardware.  Maybe things have changed in recent
> years and I could be wrong.

I haven't tried searching again yet for confirmation of this.  I'll
will try to tomorrow.  Further testing seems to point in that
direction, though.  My test system is ~5 year old Asus Chromebox with
a Celeron 2955U CPU.  I don't think it supports any of the
post-processing based deinterlacers.  When I play an mpeg2, 1080i
recording at 1x, it is jerky with any of the HW-VA deinterlacers.  The
predictive frame dropping and frame timing appear to be out of sync.
I only get smooth playback at 1x when I switch to one of the HW-GL
deinterlacers.

> Second, I'm seeing strange issues with skip and ff/rew like when the
> the mediacodec, 2x deinterlacing was first being added.  I think this
> might be realted to the first issue -- for example, a 2x deinterlacer
> is requested, but isn't actually being used and the frame timing is
> getting messed up.  I need to do some more testing to figure out
> what's going on.

I didn't get the time to recheck this yet.

> On the strange observation front, mpeg2 can't time stretch beyond
> around 1.4x without getting choppy, but h.264 can time stretch at or
> near 2x.

I think this is also related to frame dropping and predictive frame
dropping not being in sync.  I can play an mpeg2 and h.264, 1080i
recordings at 2x speed smoothly when using a 1x HW-GL deinterlacer.
Playing 720p at any speed greater than 1x and anything 1080i at any
speed greater than 1x and less than 2x is jerky with the autio and
video getting out of sync.  I think the smooth playback of 1080i at 2x
speed proves the hardware is capable of keeping up.  MythTV just won't
play it back smooth because of some other issue.

David

> David
> 
> > > At this stage vaapi and vaapi2 are both available for selection. You should
> > > be able to compile with --disable-vaapi and only have the vaapi2. These two
> > > do not use common code. I did not use any of the existing vaapi code because
> > > I could not understand what it was doing.
> > 
> > I told a coworker just two days ago that the standard practice with
> > unintelligible code is to rewrite it.  I've been there many times
> > myself.  He then told me it was his own code that he couldn't
> > understand. :)
> > 
> > David
> > 
> > > The new design caters for decoder-based deinterlacers, and these are handled
> > > in MythCodecContext and subclasses for each decoder type (currently only
> > > vaapi2). If there are other decoder based deinterlacers. Also this framework
> > > makes it possible to add ffmpeg filters, of which there are many.
> > > 
> > > For example there are these deinterlacers available which maybe could be
> > > used with software decode and may be better than the ones we have in code:
> > > 
> > >  ... kerndeint         V->V       Apply kernel deinterlacing to the input.
> > >  ... mcdeint           V->V       Apply motion compensating deinterlacing.
> > >  T.. nnedi             V->V       Apply neural network edge directed
> > > interpolation intra-only deinterlacer.
> > >  TS. w3fdif            V->V       Apply Martin Weston three field
> > > deinterlace.
> > > 
> > > Peter
> > > 
> > > 
> > 
> > > _______________________________________________
> > > mythtv-dev mailing list
> > > mythtv-dev at mythtv.org
> > > http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> > > http://wiki.mythtv.org/Mailing_List_etiquette
> > > MythTV Forums: https://forum.mythtv.org
> > 
> > 
> > -- 
> > David Engel
> > david at istwok.net
> 
> -- 
> David Engel
> david at istwok.net

-- 
David Engel
david at istwok.net