Mailing List Archive

On 05/11/2019 12:42, John Pilkington wrote:
> Hi Mark:  I see a new commit that might have fixed this - but I had
> started, so I'll finish...

Now on 99cff15, and I'm still seeing the same blockiness on steps
between adjacent keyframes.
>
> This is a niche effect but it's still there (0515eacc), even with
> progressive frames.  ffmpeg works fine.  Both work well in normal
> playback but then ffmpeg demands more of the cpus.

That should have been 'makes the cpus work harder.'
>
> Would it be feasible to switch to ffmpeg when displaying a static frame?
>
> Thanks,
>
> 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

On Tue, 5 Nov 2019 at 12:42, John Pilkington <johnpilk222@gmail.com> wrote:
>
> Hi Mark: I see a new commit that might have fixed this - but I had
> started, so I'll finish...
>
> This is a niche effect but it's still there (0515eacc), even with
> progressive frames. ffmpeg works fine. Both work well in normal
> playback but then ffmpeg demands more of the cpus.
>
> Would it be feasible to switch to ffmpeg when displaying a static frame?

John

Unfortunately I don't think that will work (without a lot of effort).

However, I've just taken a look at more recent FFmpeg fixes for
cuvid/nvdec and the following commit looks like it might fix the
problem:

https://github.com/FFmpeg/FFmpeg/commit/703583dbb1f35ccefeb8f2cccd2f99b97a4d482a#diff-1a851faa7dbf59fece61ec8d4a9920f1

I'll test it when I've kicked my nvidia box around a bit. For some
reason it can't find the opengl libs...

Peter has also just offered to resync to latest FFmpeg - so hopefully
we'll pick up sundry fixes like this.

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

On 05/11/2019 17:35, Mark Kendall wrote:
> On Tue, 5 Nov 2019 at 12:42, John Pilkington <johnpilk222@gmail.com> wrote:
>>
>> Hi Mark: I see a new commit that might have fixed this - but I had
>> started, so I'll finish...
>>
>> This is a niche effect but it's still there (0515eacc), even with
>> progressive frames. ffmpeg works fine. Both work well in normal
>> playback but then ffmpeg demands more of the cpus.
>>
>> Would it be feasible to switch to ffmpeg when displaying a static frame?
>
> John
>
> Unfortunately I don't think that will work (without a lot of effort).
>
> However, I've just taken a look at more recent FFmpeg fixes for
> cuvid/nvdec and the following commit looks like it might fix the
> problem:
>
> https://github.com/FFmpeg/FFmpeg/commit/703583dbb1f35ccefeb8f2cccd2f99b97a4d482a#diff-1a851faa7dbf59fece61ec8d4a9920f1
>
> I'll test it when I've kicked my nvidia box around a bit. For some
> reason it can't find the opengl libs...
>
> Peter has also just offered to resync to latest FFmpeg - so hopefully
> we'll pick up sundry fixes like this.

That's great - but I should clarify. When I said that ffmpeg works, I
was referring to mythffmpeg, not current ffmpeg master.
>
> 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

On 05/11/2019 18:24, John Pilkington wrote:
> On 05/11/2019 17:35, Mark Kendall wrote:

>>
>> Peter has also just offered to resync to latest FFmpeg - so hopefully
>> we'll pick up sundry fixes like this.
>
> That's great - but I should clarify.  When I said that ffmpeg works, I
> was referring to mythffmpeg, not current ffmpeg master.
>>
>> Regards
>> Mark

Amazingly d88a61dd rpms built and are running under Fedora 30.
Unfortunately that hasn't fixed the static frame blockiness, and now I'm
getting a brief shimmering effect after any jump :-(

The OSD reports 1920x1080@25fps, H.264 nvdec, 2xGLSL linearblend. The
Firestick frontend and leanfront both play - apparently as before - with
the new backend.

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

On Wed, 6 Nov 2019 at 15:55, John Pilkington <johnpilk222@gmail.com> wrote:
>
> On 05/11/2019 18:24, John Pilkington wrote:
> > On 05/11/2019 17:35, Mark Kendall wrote:
>
> >>
> >> Peter has also just offered to resync to latest FFmpeg - so hopefully
> >> we'll pick up sundry fixes like this.
> >
> > That's great - but I should clarify. When I said that ffmpeg works, I
> > was referring to mythffmpeg, not current ffmpeg master.
> >>
> >> Regards
> >> Mark
>
> Amazingly d88a61dd rpms built and are running under Fedora 30.
> Unfortunately that hasn't fixed the static frame blockiness, and now I'm
> getting a brief shimmering effect after any jump :-(

You should update again for the new nv-codec-headers - not that it
will necessarily fix anything! - but nvdec won't be enabled by the
configure script without them.

I'm not seeing any improvements with the FFmpeg update. There is at
least one regression with resolution changes - it now crashes...

Other than that there seems to be a lot of 'green frame' flashes at
startup and the various issues I have with some vp9 and hevc clips
have not been resolved. So not the greatest update!

I'll keep digging.

> The OSD reports 1920x1080@25fps, H.264 nvdec, 2xGLSL linearblend. The
> Firestick frontend and leanfront both play - apparently as before - with
> the new backend.

Any reason you are using GLSL (i.e. shaders) rather than the nvdec
deinterlacer? Just curious.

With respect to your previous report re mythffmpeg - what command line
are you using? I'm pretty sure mythffmpeg won't be using any form of
direct rendering, so probably not a meaningful comparison with the
myth code at present (and will also be why it is using more CPU).

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

On 06/11/2019 16:07, Mark Kendall wrote:
> On Wed, 6 Nov 2019 at 15:55, John Pilkington <johnpilk222@gmail.com> wrote:
>>
>> On 05/11/2019 18:24, John Pilkington wrote:
>>> On 05/11/2019 17:35, Mark Kendall wrote:
>>
>>>>
>>>> Peter has also just offered to resync to latest FFmpeg - so hopefully
>>>> we'll pick up sundry fixes like this.
>>>
>>> That's great - but I should clarify. When I said that ffmpeg works, I
>>> was referring to mythffmpeg, not current ffmpeg master.
>>>>
>>>> Regards
>>>> Mark
>>
>> Amazingly d88a61dd rpms built and are running under Fedora 30.
>> Unfortunately that hasn't fixed the static frame blockiness, and now I'm
>> getting a brief shimmering effect after any jump :-(
>
> You should update again for the new nv-codec-headers - not that it
> will necessarily fix anything! - but nvdec won't be enabled by the
> configure script without them.

but the startup check and the OSD say nvdec is in use. ?

> I'm not seeing any improvements with the FFmpeg update. There is at
> least one regression with resolution changes - it now crashes...
>
> Other than that there seems to be a lot of 'green frame' flashes at
> startup and the various issues I have with some vp9 and hevc clips
> have not been resolved. So not the greatest update!
>
> I'll keep digging.
>
>> The OSD reports 1920x1080@25fps, H.264 nvdec, 2xGLSL linearblend. The
>> Firestick frontend and leanfront both play - apparently as before - with
>> the new backend.
>
> Any reason you are using GLSL (i.e. shaders) rather than the nvdec
> deinterlacer? Just curious.

It's what I get when I select 'Medium quality deinterlacers' and 'Prefer
OpenGL deinterlacers.' No other reason. The hardware drivers
mentioned don't include nvdec - only VDPAU and VAAPI.

And 'Current Video Playback Profile' offers 'Normal', 'NVDEC Normal',
and others which seemed less likely to match my hardware. My
understanding is that 'Normal' would give the myth-specific ffmpeg, aka
mythffmpeg, in the versions before or after yesterday's re-sync.

That setting appears to carry over to the next page.

I really don't know which options 'ought' to be best...


>
> With respect to your previous report re mythffmpeg - what command line
> are you using? I'm pretty sure mythffmpeg won't be using any form of
> direct rendering, so probably not a meaningful comparison with the
> myth code at present (and will also be why it is using more CPU).
>
> 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

Now running 0822d3c with nVidia 430.40, and using High quality nvdec
deinterlacing on a BBC DVB-T2 HD recording. Static pictures are still
often blocky and the 'new' shimmer after a skip is still there, but the
most obvious new feature looks like bad frame ordering when an OSD is
present; particularly the display of playback data. Linear playback is
good.

I see rpmfusion-testing now has nVidia 440.31 I'll try that.

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

John

I've just pushed a fix for direct rendering - solves the green flashes
I was seeing and sundry issues with out of order frames.

Running through my test clips and samples this gives flawless playback
of VP9 up to 5k/30fps (probably 60fps as well but I don't have any
samples for that), HEVC 4k/60fps and H264 4k/60fps. It tries hard with
8k vp9 but runs out of memory:)

For reference, this is a GT1030 with 420.26 drivers.

I did have to adjust my audio read ahead settings to get some of these
files playing well - but that is a different issue.

The only remaining problem I see is the corruption around seeks. This
appears to only occur with interlaced H624.

The same corruption is seen when using nvdec-dec as the decoder (i.e.
copyback) and when using mythffplay - both of which are using
'vanilla' ffmpeg code with no direct rendering. A quick check with mpv
(which is using direct rendering I think, on top of ffmpeg) produces
the same issues.

So in short, this is almost certainly an FFmpeg and/or cuda issue but
I can't find any bug reports relating to it.

Regards
Mark

On Wed, 6 Nov 2019 at 23:19, John Pilkington <johnpilk222@gmail.com> wrote:
>
> Now running 0822d3c with nVidia 430.40, and using High quality nvdec
> deinterlacing on a BBC DVB-T2 HD recording. Static pictures are still
> often blocky and the 'new' shimmer after a skip is still there, but the
> most obvious new feature looks like bad frame ordering when an OSD is
> present; particularly the display of playback data. Linear playback is
> good.
>
> I see rpmfusion-testing now has nVidia 440.31 I'll try that.
>
> 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
_______________________________________________
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

On 07/11/2019 13:08, Mark Kendall wrote:
> John
>
> I've just pushed a fix for direct rendering - solves the green flashes
> I was seeing and sundry issues with out of order frames.

Yes, that (9eba7cc) seems to have fixed it for me too. The same BBC HD
recording now plays smooth and crisp, with or without playback data
displayed, in Fedora 30 with nVidia 440.31

And when the editor's skip to a keyframe gives a blocky picture, going
back one frame gives clarity - and a burst of sound...

>
> Running through my test clips and samples this gives flawless playback
> of VP9 up to 5k/30fps (probably 60fps as well but I don't have any
> samples for that), HEVC 4k/60fps and H264 4k/60fps. It tries hard with
> 8k vp9 but runs out of memory:)
>
> For reference, this is a GT1030 with 420.26 drivers.
>
> I did have to adjust my audio read ahead settings to get some of these
> files playing well - but that is a different issue.
>
> The only remaining problem I see is the corruption around seeks. This
> appears to only occur with interlaced H624.
>
> The same corruption is seen when using nvdec-dec as the decoder (i.e.
> copyback) and when using mythffplay - both of which are using
> 'vanilla' ffmpeg code with no direct rendering. A quick check with mpv
> (which is using direct rendering I think, on top of ffmpeg) produces
> the same issues.
>
> So in short, this is almost certainly an FFmpeg and/or cuda issue but
> I can't find any bug reports relating to it.
>
> Regards
> Mark
>
> On Wed, 6 Nov 2019 at 23:19, John Pilkington <johnpilk222@gmail.com> wrote:
>>
>> Now running 0822d3c with nVidia 430.40, and using High quality nvdec
>> deinterlacing on a BBC DVB-T2 HD recording. Static pictures are still
>> often blocky and the 'new' shimmer after a skip is still there, but the
>> most obvious new feature looks like bad frame ordering when an OSD is
>> present; particularly the display of playback data. Linear playback is
>> good.
>>
>> I see rpmfusion-testing now has nVidia 440.31 I'll try that.
>>
>> 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