[mythtv] FFmpeg 4.4.1 problems

[John Pilkington]

On 19/11/2021 20:34, Klaas de Waal wrote:
> 
> 
> On Thu, 18 Nov 2021 at 21:40, Piotr Oniszczuk <piotr.oniszczuk at gmail.com 
> <mailto:piotr.oniszczuk at gmail.com>> wrote:
> 
>     Guys,
> 
>     Original idea with 4.4 upstream + mythtv functional patches was to
>     find(*) regressing downstream commit.
>     I think - to have valid conclusion about root cause we NEED revert
>     commits & test _under mythtv_ - not on other ffmpeg consumers.
> 
>     (*) as mythtv ffmpeg was incrementally down-streaming with more and
>     more extra functionality - better strategy imho is backward
>     reverting instead of bisecting.
>     (i suspect interdependencies will probably make bisection quite
>     quickly failing: non-compile or non-working)
> 
> 
> 
> @Peter Bennett <mailto:pb.mythtv at gmail.com> Very good point. I did use 
> the " -vcodec h264_cuvid"  option  and this did increase the GPU memory 
> usage from 6Mb to 130Mb or so as shown by the nvidia-smi command. It 
> also reduced the CPU load a lot so this did really use hardware 
> decoding. However, this is probably the same as NVENC and not VDPAU as 
> you correctly pointed out. Nevertheless, there were also blocking 
> artifacts with NVENC that I have not seen with ffplay.
> @Piotr Oniszczuk <mailto:piotr.oniszczuk at gmail.com>  I think you are 
> correct that getting MythTV to work with an unmodified (as much as 
> possible) version of ffmpeg, checking if playback works correctly, and 
> then adding the MythTV modifications one by one and keep on checking is 
> the best approach.
> This looks feasible as the MythTV modifications are not that many, 
> compared to the whole of ffmpeg.
> If there is an issue with playback using an (as much as possible) 
> unmodified version of ffmpeg then we are back to figuring out which 
> ffmpeg commit makes a difference, but we can cross that bridge when we 
> meet it....
> 
> N.B. I do enjoy the cooperation in getting this resolved. Thanks!
> 
> Klaas.
> 

I'm not sure where the current focus is in the ffmpeg-resync trail, but 
the problems with skipping in NVDEC go back much further.  Most of my 
input has been about use with the cutlist editor, when the picture is 
static, but a solution seemed unlikely and I switched to the 'Normal' 
profile for editing.  See, for example,  Mark_K's comment from 20 months 
ago:

> The
> bigger issue is that when NVDEC deinterlacing is enabled, short
> backwards seeks are totally innacurate. 

here

https://lists.archive.carbon60.com/mythtv/dev/629830#629830

John P