[mythtv] FFmpeg 4.4.1 problems

[Peter Bennett]

On 11/13/21 3:35 PM, Klaas de Waal wrote:
>
>
> On Fri, 12 Nov 2021 at 21:46, David Engel <david at istwok.net 
> <mailto:david at istwok.net>> wrote:
>
>     On Fri, Nov 12, 2021 at 08:39:58PM +0100, 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.
>
>     The same goes for me.  As an example, the local commercials inserted
>     by my cable company are often in stereo where as the main program is
>     in AC3 5.1.  There stereo commercials are noticeably and annoyingly
>     much louder than the normal program.  As far as I can tell, that'sdue
>     to a bug in my Nvidia Shield.  I finally found a work around by
>     turning on upconvert stero to 5.1 in MythTV even though I only have
>     stereo speakers.  I quickly turned off the work around beacuse
>     skipping went from 50-100ms to 200-250ms.  I know it doesn't sound
>     like much but to someone who skips a lot, it is a huge downgrade.
>
>     > 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.
>
>     Does h264 have true keyframes?  I vaguely recall something from long,
>     long ago that h264 (or perhaps some other new encoding) doesn't have
>     or doesn't have to have true keyframes where a complete, new frame is
>     started at a specific place in the stream.  Is is possible the source
>     of Klaas' recordings isn't including optional keyframes?
>
>     Alternativiely, maybe there's a bug in MythTV's h264 keyframe
>     detector.  There was in bug in MythTV several years ago where the
>     mpeg2 keyframe detector would automatically and incorrectly mark every
>     15th or 30th frame as a keyframe if a real keyframe wan't detected
>     "soon" enough.  One of my channels switched from the normal every
>     0.5s/15 frames, keyframe interval at the time to 2.5s/75 frames.  Most
>     but not all skips on recordings from that channel started showing
>     blocking and artifacts.
>
> The current mythtv-master plays back OK so I think the keyframes are OK.
> Also, I play recordings back as a video and then it does not use 
> keyframes but seeks with libavformat. The problem is then the same.
>
>     Klaas, does the same blocking occur when you play your recordings back
>     with something like mpv?
>
> I have tried playing the file tweevoortwaalf_ffmpeg.ts with the 
> following commands:
> $ vpw
> $ vpw -vo=vdpau
> $ vpw -vo=gpu
> $ vpw -vo=gpu -hwdec=vdpau
> $ vpw -vo=gpu -hwdec=nvdec
> Playback and skipping is OK with all of them.
> This suggests a possible way forward is to look at the vpw code for 
> inspiration.
>
> Klaas.

What is vpw? I cannot find any video player called vpw. Also, does it 
use FFmpeg 4.4.1?

Peter

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