[mythtv] render2019: step-length oddities in video editing
mark.kendall at gmail.com
Mon Oct 7 11:10:22 UTC 2019
On Mon, 7 Oct 2019 at 10:12, John Pilkington <johnpilk222 at gmail.com> wrote:
> On 07/10/2019 09:28, Mark Kendall wrote:
> > On Sun, 6 Oct 2019 at 19:10, John Pilkington <johnpilk222 at gmail.com> wrote:
> >> Hi Mark, thanks for the response: I have just looked at the step
> >> lengths in the editor in last night's ppa build of master for ubuntu
> >> 18.04, and the 1-frame, 0.5-sec, 1-sec steps that are broken in render
> >> 2019 all work as expected, although 1-sec is a bit elastic.
> >> The blurriness in static frames in render 2019 is probably a mix of info
> >> from several frames and doesn't really affect editing, but it is
> >> different. Normal playback seems fine.
> > John
> > I've pushed a fix for a regression in seeking that seems to fix the
> > worst of the seeking issues. Editing seems fine here with software
> > decode and VAAPI direct rendering. VAAPI decode only still gives some
> > odd seeks for reasons I don't understand. Deinterlacing seems to be
> > working OK and I can't see/reproduce the blurriness that you mention.
> > Can you give me details of your decoder/deinterlacer settings?
> > Apart from the VAAPI decode only anomaly, there is a slight oddity
> > with 1 second seeking in a PAL recording where it seeks 24 frames
> > instead of 25. I suspect this is a master issue as well (mythplayer
> > actually asks to seek 24 frames). NTSC recording (imported) always
> > seeks 30.
> > Frame by frame seeking in videos (i.e. no seektable) still has issues
> > when going backwards - again not sure why:)
> > regards
> > Mark
> OK, thanks, I should have a build later. The bad decoding of static
> pictures has been most noticeable in 544x576 h264 content as from DVB-T
> Smithsonian (99) and PBS America (91), using nvdec and 2xGLSL
> linearblend. I've also had segfaults while doing the tests, but haven't
> investigated those.
Quick test with the nvidia machine.
The static image problem appears to be specific to nvdec when seeking
to a keyframe. It's not deinterlacer related.
If nvdec deinterlacing is used then seeks are erratic again. This will
be because the frames are being filtered somewhere in the black box of
the cuda code - not sure that is fixable, I'll have to take a look.
The problem here is that nvdec hardware deinterlacing is a one time
setup when the decoder is created - we lose all control of what
cuda/nvdec is actually doing and cannot turn it off again. This is
probably the same issue with VAAPI decode only and hardware
deinterlacing - the frames are being filtered in the decoder which is
throwing out the seek - although in this case it can be turned on/off
More information about the mythtv-dev