Mailing List Archive

render2019: step-length oddities in video editing
I use the editor to establish cutpoints in almost all my recordings,
cutting at keyframes. In 2019render 33b109b1106e the static images
shown at keyframes are often blurred, but stepping forward and back by
keyframes is consistent.

Nominal 1-frame steps forward are OK, and advancing around 7 frames
usually gives a better image; but steps back are by keyframe intervals.
Nominal 0.5-second steps do the same, and nominal 1-second steps seem to
go to keyframes in both directions. The larger steps aren't exact, but
near enough.

I've tried this with both h264 and mpeg2 recordings. I haven't done a
direct comparison with master, but the feel is different.

John P
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019: step-length oddities in video editing [ In reply to ]
On Sun, 6 Oct 2019 at 12:48, John Pilkington <johnpilk222@gmail.com> wrote:
>
> I use the editor to establish cutpoints in almost all my recordings,
> cutting at keyframes. In 2019render 33b109b1106e the static images
> shown at keyframes are often blurred, but stepping forward and back by
> keyframes is consistent.

There is no reason that images would be blurred. The only change in
behaviour I can think of is that the render branch code will
deinterlace the 'pause' frame when it can/should (i.e. interlacing is
detected and deinterlacing is enabled).

I may need to check exactly what is happening with some of the more
advanced deinterlacers to make sure we get the correct frame when
multiple reference frames are needed - but I *think* they should be
OK:)

> Nominal 1-frame steps forward are OK, and advancing around 7 frames
> usually gives a better image; but steps back are by keyframe intervals.
> Nominal 0.5-second steps do the same, and nominal 1-second steps seem to
> go to keyframes in both directions. The larger steps aren't exact, but
> near enough.
>
> I've tried this with both h264 and mpeg2 recordings. I haven't done a
> direct comparison with master, but the feel is different.

I noticed some time ago that frame by frame seeking was
inconsistent/erratic. Seeking forwards seems to often jump a little on
the first seek and then works OK. Seeking backwards is much worse.
David mentioned it a while back on IRC and believes it is a fairly
long standing regression in master. There may well be other issues in
the render branch of course:)

Thanks and regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019: step-length oddities in video editing [ In reply to ]
On 06/10/2019 18:29, Mark Kendall wrote:
> On Sun, 6 Oct 2019 at 12:48, John Pilkington <johnpilk222@gmail.com> wrote:
>>
>> I use the editor to establish cutpoints in almost all my recordings,
>> cutting at keyframes. In 2019render 33b109b1106e the static images
>> shown at keyframes are often blurred, but stepping forward and back by
>> keyframes is consistent.
>
> There is no reason that images would be blurred. The only change in
> behaviour I can think of is that the render branch code will
> deinterlace the 'pause' frame when it can/should (i.e. interlacing is
> detected and deinterlacing is enabled).
>
> I may need to check exactly what is happening with some of the more
> advanced deinterlacers to make sure we get the correct frame when
> multiple reference frames are needed - but I *think* they should be
> OK:)
>
>> Nominal 1-frame steps forward are OK, and advancing around 7 frames
>> usually gives a better image; but steps back are by keyframe intervals.
>> Nominal 0.5-second steps do the same, and nominal 1-second steps seem to
>> go to keyframes in both directions. The larger steps aren't exact, but
>> near enough.
>>
>> I've tried this with both h264 and mpeg2 recordings. I haven't done a
>> direct comparison with master, but the feel is different.
>
> I noticed some time ago that frame by frame seeking was
> inconsistent/erratic. Seeking forwards seems to often jump a little on
> the first seek and then works OK. Seeking backwards is much worse.
> David mentioned it a while back on IRC and believes it is a fairly
> long standing regression in master. There may well be other issues in
> the render branch of course:)
>
> Thanks and regards
> Mark

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.

Thanks,

John



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019: step-length oddities in video editing [ In reply to ]
On Sun, 6 Oct 2019 at 19:10, John Pilkington <johnpilk222@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
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019: step-length oddities in video editing [ In reply to ]
On 07/10/2019 09:28, Mark Kendall wrote:
> On Sun, 6 Oct 2019 at 19:10, John Pilkington <johnpilk222@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.

John

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019: step-length oddities in video editing [ In reply to ]
On Mon, 7 Oct 2019 at 10:12, John Pilkington <johnpilk222@gmail.com> wrote:
>
> On 07/10/2019 09:28, Mark Kendall wrote:
> > On Sun, 6 Oct 2019 at 19:10, John Pilkington <johnpilk222@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
as needed.

Regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019: step-length oddities in video editing [ In reply to ]
On 07/10/2019 12:10, Mark Kendall wrote:
> On Mon, 7 Oct 2019 at 10:12, John Pilkington <johnpilk222@gmail.com> wrote:
>>
>> On 07/10/2019 09:28, Mark Kendall wrote:
>>> On Sun, 6 Oct 2019 at 19:10, John Pilkington <johnpilk222@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
> as needed.
>
> Regards
> Mark

I confirm that the step-length problem has gone. Great!

Using HDMI output on 1080 content (Strictly...) some static pictures
remain confused, and the AOG (Audio Output Graph) often has multiple
'append discontinuity' complaints then. I spent some time trying to fix
the AOG some time ago, but since it didn't break anything else I
eventually gave up. I'll perhaps experiment more with the deinterlacing...

Thanks,

John


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org