[mythtv] FFmpeg 4.4.1 problems

[Peter Bennett]

On 11/12/21 2:39 PM, Klaas de Waal wrote:
>
>
> On Fri, 12 Nov 2021 at 15:46, Peter Bennett <pb.mythtv at gmail.com 
> <mailto:pb.mythtv at gmail.com>> wrote:
>
>     David
>
>     I saw your commit for reducing prebuffer.
>
>     I am trying to get ffmpeg 4.4.1 in shape in the devel/ffmpeg-resync
>     branch. Klaas has reported picture corruption which sometimes
>     happens at
>     start of play or after a jump and lasts up to 2 seconds. This happens
>     with VDPAU on interlaced H264 videos. Also to a lesser extent with
>     NVDEC
>     on interlaced H264 videos (only lasts a small fraction of a second
>     with
>     NVDEC as far as I have seen). it only happens on about one out of ten
>     jumps on VDPAU.
>
>     The workaround I am looking at is to "prime" the decoder with an
>     extra 2
>     seconds of data that are not shown, so that the first picture seen
>     will
>     not be corrupted. This would cause a small delay after a jump,
>     which may
>     be unacceptable, or may be less acceptable that seeing a couple of
>     seconds of corruption. I don't know if this is a good workaround.
>
>     For fast forward or rewind this would not make sense so it would
>     have to
>     be suppressed.
>
>     Let me know if anybody has any suggestions, better ideas, etc.
>
>     Peter
>
> The capability to skip very fast is the key feature that 
> differentiates MythFrontend from other players and that I use 
> extensively to skip past commercials in small increments. So I would 
> rather not lose this feature. Skipping with VDPAU has worked perfectly 
> for the last 15 years...  I prefer not upgrading to the latest FFmpeg 
> if slower skipping is the consequence, also because I do not have any 
> issues with the FFmpeg that we are currently using.
>
> About the possible cause, I can digress a little although it is mostly 
> conjecture.
> The artifacts also appear with older recordings so it is purely a 
> playback issue. This means that the keyframe index (if that is what it 
> is called) generation in mythbackend is likely still OK. That limits 
> the problem to playback.
> It could be that there is an issue in passing the jump position as 
> read from the database to FFmpeg/decoder. Although I expect it is 
> difficult to do this "a little bit" wrong; this kind of thing either 
> crashes or works OK probably.
>
> I think that I observed that when my mythfrontend is just powered up, 
> skipping is OK at the start and that it does deteriorate after a 
> while. This suggests that, when doing a skip, there must be something 
> additional initialized/reset in FFmpeg/decoder.
>
> For me the issue only appears with H264 interlaced. H265 progressive 
> is OK. My guess is that H264 progressive would also be OK and that the 
> issue is connected to the interlacing. This then could be related to 
> top field/bottom field not being passed correctly or interpreted 
> reverse or so.
> As said, mostly conjecture.... But I hope that this helps a bit.
>
> Thanks,
> Klaas.
>
One thing that I noticed with the sample you supplied: If I start 
playing from the beginning, the first couple of seconds are badly 
corrupted. However if I let it carry on and then left arrow to the 
beginning again, it plays the first scene perfectly.

I did try playing around with the keyframe, but it seems that is not the 
problem. There does seem to be a keyframe at the beginning and we still 
get the problem.

That first scene that is corrupted - if you pause and look at it 
carefully you can see the man's face on the top and the bottom half, 
among the mess. I think maybe it is doing something wrong while merging 
the two interlaced fields into one picture.

I do not understand the OpenGL rendering of the picture and how the 
deinterlacing works, so I am unable to do anything there to fix it.

James Abernathy reported a problem with the start of play on VAAPI, with 
interlaced MPEG-2. I still need to look at that.

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20211112/8f734770/attachment.htm>