[mythtv] FFmpeg 4.4.1 problems
John Pilkington
johnpilk222 at gmail.com
Mon Nov 15 23:28:54 UTC 2021
On 15/11/2021 19:57, Klaas de Waal wrote:
>
>
> On Mon, 15 Nov 2021 at 15:49, Peter Bennett <pb.mythtv at gmail.com
> <mailto:pb.mythtv at gmail.com>> wrote:
>
>
> On 11/14/21 5:21 AM, Klaas de Waal wrote:
>>
>>
>> On Sat, 13 Nov 2021 at 23:45, Peter Bennett <pb.mythtv at gmail.com
>> <mailto:pb.mythtv at gmail.com>> wrote:
>>
>>
>> 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?
>>
>>
>> Oops, typo..... Should not do anything too late....
>> The player is mpv which is a variant of mplayer.
>> The version I used is what is in Fedora 35 and reports FFmpeg 4.4
>>
>> Klaas.
>
> I upgraded my ubuntu version of ffmpeg to 4.4.1 and installed mpv.
> mpv reports:
>
> peter at rocinante:~$ mpv --version
> mpv 0.32.0 Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
> built on UNKNOWN
> ffmpeg library versions:
> libavutil 56.31.100 (runtime 56.70.100)
> libavcodec 58.54.100 (runtime 58.134.100)
> libavformat 58.29.100 (runtime 58.76.100)
> libswscale 5.5.100 (runtime 5.9.100)
> libavfilter 7.57.100 (runtime 7.110.100)
> libswresample 3.5.100 (runtime 3.9.100)
> ffmpeg version: 4.4.1-0ubuntu1~20.04.sav0
>
> Playing with mpv is perfect, as you noted
>
> mpv -vo=vdpau -deinterlace
> '/home/storage/Video/mythtv-local/Videos/vdpau corruption.ts'
>
> This indicates that the problem is either with the rendering code in
> MythTV or the modifications we have made to ffmpeg over the years.
>
> I do not have much knowledge of OpenGL or how the rendering works,
> so I am stuck on how to fix this.
>
> Actually understanding all the code is the most difficult way to fix
> bugs...
> I was thinking of the following.
> Given that mythtv-master does work OK the only differences are in
> the FFmpeg updates and the additional changes in mythtv code needed for
> this.
> The branch devel/ffmpeg-resync has all FFMpeg changes in one commit.
> Would it be possible to to create a branch equivalent to devel/ffmpeg
> but then with all FFmpeg commits and the additional changes in mythtv
> code as separate commits?
> This would then make it possible to use git bisect.
> This new branch would never need to get merged into the master, it is
> only needed to find the offending commit and then it is doable to find a
> fix.
> I can have a go at the bisecting if there is a branch with all
> individual commits.
>
> Klaas.
>
I have Klaas' file, now stripped to 1 vid and 1 audio stream, in F34. I
see blocking in mythfrontend with vdpau, and less-blocky disturbances
with nvdec. Similarly with other h264 recordings. But mpv isn't
perfect, either, on skipping. Using 'mpv -vo=gpu $filename' (which it
suggested instead of vdpau), it complains about 'reference picture
missing during reorder' and there is often transient blocking. Straight
playback is fine, and the skips are quick.
This file, and an earlier one from YLE, is said to have 'no iframes'
when 'mythcommflag --rebuild --file $filename' creates a seektable.
Files recorded locally from DVB don't give this warning.
There was an update today and both mpv and mpv-libs are now at 0.34.0-1,
while mpv -version shows FFmpeg 4.4.1
John P
More information about the mythtv-dev
mailing list