Mailing List Archive

On Fri, 12 Nov 2021 at 15:46, Peter Bennett <pb.mythtv@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.

On 11/12/21 2:39 PM, Klaas de Waal wrote:
>
>
> On Fri, 12 Nov 2021 at 15:46, Peter Bennett <pb.mythtv@gmail.com
> <mailto:pb.mythtv@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

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@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.

Klaas, does the same blocking occur when you play your recordings back
with something like mpv?

David

>
> Thanks,
> Klaas.

--
David Engel
david@istwok.net
_______________________________________________
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 Fri, 12 Nov 2021 at 21:46, David Engel <david@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@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.

On 11/13/21 3:35 PM, Klaas de Waal wrote:
>
>
> On Fri, 12 Nov 2021 at 21:46, David Engel <david@istwok.net
> <mailto:david@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@gmail.com
> <mailto:pb.mythtv@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

On Sat, 13 Nov 2021 at 23:45, Peter Bennett <pb.mythtv@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@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@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.

On 11/14/21 5:21 AM, Klaas de Waal wrote:
>
>
> On Sat, 13 Nov 2021 at 23:45, Peter Bennett <pb.mythtv@gmail.com
> <mailto:pb.mythtv@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@istwok.net
>> <mailto:david@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@gmail.com <mailto:pb.mythtv@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@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.

Peter

On Mon, 15 Nov 2021 at 15:49, Peter Bennett <pb.mythtv@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@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@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@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@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.

On 15/11/2021 19:57, Klaas de Waal wrote:
>
>
> On Mon, 15 Nov 2021 at 15:49, Peter Bennett <pb.mythtv@gmail.com
> <mailto:pb.mythtv@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@gmail.com
>> <mailto:pb.mythtv@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@istwok.net
>>> <mailto:david@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@gmail.com <mailto:pb.mythtv@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@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
_______________________________________________
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 11/15/21 2:57 PM, Klaas de Waal wrote:
>
>
> On Mon, 15 Nov 2021 at 15:49, Peter Bennett <pb.mythtv@gmail.com
> <mailto:pb.mythtv@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@gmail.com
>> <mailto:pb.mythtv@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@istwok.net
>>> <mailto:david@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@gmail.com <mailto:pb.mythtv@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@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 am not sure how to do that. The MythTV version of ffmpeg is in the
github repository MythTV/FFmpeg. Note that in there the real master is
new-master. The "master" branch is bad, I still need to fix that,
probably by renaming new-master to master.

The release/4.4 branch is what we are using. In that branch you can see
all the ffmpeg commits. They have been merged from the main ffmpeg
repository release/4.4 branch. After merging and fixing all the
conflicts and compile errors, I just copy the entire structure, all
files, into the mythtv/external/FFmpeg directory.

The problem is in the MythTV/FFmpeg repository there is a tree like this:

* 18afbb8c42 2021/10/31 Peter Bennett : Fix compile errors after merge
*   d295b63bda 2021/10/30 Peter Bennett : Merge tag 'n4.4.1' into
release/4.4
|\
| * 7e0d640edf 2021/10/23 Michael Niedermayer : Changelog: update
| * 73e60e4439 2021/10/23 Michael Niedermayer : avcodec/flac_parser:
Consider AV_INPUT_BUFFER_PADDING_SIZE
| * 404c9331dd 2021/10/21 Michael Niedermayer : avcodec/ttadsp: Fix
integer overflows in tta_filter_process_c()
| * 875fbddd7d 2021/10/21 Michael Niedermayer : avutil/mathematics:
Document av_rescale_rnd() behavior on non int64 re..
| * 32b68a6232 2021/10/21 Michael Niedermayer : avcodec/utils: Ensure
8x8 alignment for ARGO in avcodec_align_dimensio..

...another couple hundred commits from Michael Niedermayer

| * cfe614787d 2021/03/21 Derek Buitenhuis : avformat/mov: Fix extended
atom size buffer length check
| * 7efe57ba11 2021/03/21 James Almer   : avformat: remove
FF_API_INIT_PACKET from AVStream.attached_pic
| * da4d578621 2021/03/20 Michael Niedermayer : Update versions for 4.4
* | 5abfeff78a 2021/10/30 ulmus-scott   : fix non UTF-8 files (external)
* | 4a52936a03 2021/10/30 Klaas de Waal : Update changed streams on PMT
update
* | f6663afec2 2021/10/30 Peter Bennett : Merge commit 'c67d2a2875' into
base4.4
|\|
| * c67d2a2875 2021/03/20 Michael Niedermayer : Bump Versions before
release/4.4 branch
| * 17cf309dfa 2021/03/20 Michael Niedermayer : doc/APIchanges: fill in
missing fields
| * 33a1687bf6 2021/03/20 Michael Niedermayer : avcodec/mpeg4videoenc:
Check extradata malloc()

... more

Only those commits with asterisk as the first character have the MythTV
customizations. All the others (about 335) with Michael Niedermayer and
others will give you pure FFmpeg code with none of the MythTV
customizations until merged. So I suppose what is needed is to merge at
different points within those hundreds of commits, fix the errors and
conflicts, and test.

Perhaps some sort of rebase instead of merge would have helped. I am not
sure how to do that or if it would work. Perhaps another alternative is
cherry-pick each commit.

The procedure I follow for the ffmpeg update is in the following file in
the ffmpeg-resync branch:

https://github.com/MythTV/mythtv/blob/devel/ffmpeg-resync/mythtv/external/FFmpeg-sync-instructions.txt

Peter

> Wiadomo?? napisana przez Peter Bennett <pb.mythtv@gmail.com> w dniu 16.11.2021, o godz. 01:51:
>
> I am not sure how to do that. The MythTV version of ffmpeg is in the github repository MythTV/FFmpeg. Note that in there the real master is new-master. The "master" branch is bad, I still need to fix that, probably by renaming new-master to master.
>
> The release/4.4 branch is what we are using. In that branch you can see all the ffmpeg commits. They have been merged from the main ffmpeg repository release/4.4 branch. After merging and fixing all the conflicts and compile errors, I just copy the entire structure, all files, into the mythtv/external/FFmpeg directory.
>
> The problem is in the MythTV/FFmpeg repository there is a tree like this:
>
> * 18afbb8c42 2021/10/31 Peter Bennett : Fix compile errors after merge
> * d295b63bda 2021/10/30 Peter Bennett : Merge tag 'n4.4.1' into release/4.4
> |\
> | * 7e0d640edf 2021/10/23 Michael Niedermayer : Changelog: update
> | * 73e60e4439 2021/10/23 Michael Niedermayer : avcodec/flac_parser: Consider AV_INPUT_BUFFER_PADDING_SIZE
> | * 404c9331dd 2021/10/21 Michael Niedermayer : avcodec/ttadsp: Fix integer overflows in tta_filter_process_c()
> | * 875fbddd7d 2021/10/21 Michael Niedermayer : avutil/mathematics: Document av_rescale_rnd() behavior on non int64 re..
> | * 32b68a6232 2021/10/21 Michael Niedermayer : avcodec/utils: Ensure 8x8 alignment for ARGO in avcodec_align_dimensio..
>
> ...another couple hundred commits from Michael Niedermayer
>
> | * cfe614787d 2021/03/21 Derek Buitenhuis : avformat/mov: Fix extended atom size buffer length check
> | * 7efe57ba11 2021/03/21 James Almer : avformat: remove FF_API_INIT_PACKET from AVStream.attached_pic
> | * da4d578621 2021/03/20 Michael Niedermayer : Update versions for 4.4
> * | 5abfeff78a 2021/10/30 ulmus-scott : fix non UTF-8 files (external)
> * | 4a52936a03 2021/10/30 Klaas de Waal : Update changed streams on PMT update
> * | f6663afec2 2021/10/30 Peter Bennett : Merge commit 'c67d2a2875' into base4.4
> |\|
> | * c67d2a2875 2021/03/20 Michael Niedermayer : Bump Versions before release/4.4 branch
> | * 17cf309dfa 2021/03/20 Michael Niedermayer : doc/APIchanges: fill in missing fields
> | * 33a1687bf6 2021/03/20 Michael Niedermayer : avcodec/mpeg4videoenc: Check extradata malloc()
>
> ... more
>
> Only those commits with asterisk as the first character have the MythTV customizations. All the others (about 335) with Michael Niedermayer and others will give you pure FFmpeg code with none of the MythTV customizations until merged. So I suppose what is needed is to merge at different points within those hundreds of commits, fix the errors and conflicts, and test.
>
> Perhaps some sort of rebase instead of merge would have helped. I am not sure how to do that or if it would work. Perhaps another alternative is cherry-pick each commit.
>
> The procedure I follow for the ffmpeg update is in the following file in the ffmpeg-resync branch:
>
> https://github.com/MythTV/mythtv/blob/devel/ffmpeg-resync/mythtv/external/FFmpeg-sync-instructions.txt
>
> Peter
>

Peter,

This whole situation is imho usual example of case where downstream code changes potentially introducing regressions.
This happens not so rare in various projects i'm following.

In such case critical is to have clear visibility of downstream changes - very useful to nail-down particular change being root cause for regression.
imho best way to do this effectively is to have downstream as:

4.4 downstream: 4.4 upstream + mythtv downstream changes

instead of

4.4 downstream: 4.3 downstream + 4.4 upstream back-ports + mythtv downstream changes


First model has imho at least following benefits:
-offers clear view on downstream code changes i.e. for review (including peer review)
-is almost mandatory for upstreaming
-needed to properly expose intellectual property (imho mandatory habit in FOSS)
-makes future rebases much easier (imho)

Second model (i believe current model we are using) has imho following issues (at least for me):
-very difficult to find root causes introduced at down-streaming. (peer review by i.e. invited 3rd party devs is practically impossible)
-not addressing potential upstreaming at all
-practically losses intellectual property info about downstream code
-more work is needed at rebasinng
-makes approach with shared FFmpeg practically impossible (i mean common system FFmpeg used by MythTV and other apps i.e. Kodi or mpv ro whatever)(*)
(shared FFmpeg can help for regressions testing + can improve maintenance by code reuse)


btw: some time ago i already proposed above to Mark Kendal for change to model 1 - but received no any reaction/comment on this....

(*) - I already do experiment with Kodi using MythTV FFmpeg: Kodi fails to properly decode video with V4l2_request - even when working Kodi FFmpeg & MythTV FFmepg have exactly the same V4l2_request code....





_______________________________________________
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 11/16/21 6:21 AM, Piotr Oniszczuk wrote:
>
>> Wiadomo?? napisana przez Peter Bennett <pb.mythtv@gmail.com> w dniu 16.11.2021, o godz. 01:51:
>>
>> I am not sure how to do that. The MythTV version of ffmpeg is in the github repository MythTV/FFmpeg. Note that in there the real master is new-master. The "master" branch is bad, I still need to fix that, probably by renaming new-master to master.
>>
>> The release/4.4 branch is what we are using. In that branch you can see all the ffmpeg commits. They have been merged from the main ffmpeg repository release/4.4 branch. After merging and fixing all the conflicts and compile errors, I just copy the entire structure, all files, into the mythtv/external/FFmpeg directory.
>>
>> The problem is in the MythTV/FFmpeg repository there is a tree like this:
>>
>> * 18afbb8c42 2021/10/31 Peter Bennett : Fix compile errors after merge
>> * d295b63bda 2021/10/30 Peter Bennett : Merge tag 'n4.4.1' into release/4.4
>> |\
>> | * 7e0d640edf 2021/10/23 Michael Niedermayer : Changelog: update
>> | * 73e60e4439 2021/10/23 Michael Niedermayer : avcodec/flac_parser: Consider AV_INPUT_BUFFER_PADDING_SIZE
>> | * 404c9331dd 2021/10/21 Michael Niedermayer : avcodec/ttadsp: Fix integer overflows in tta_filter_process_c()
>> | * 875fbddd7d 2021/10/21 Michael Niedermayer : avutil/mathematics: Document av_rescale_rnd() behavior on non int64 re..
>> | * 32b68a6232 2021/10/21 Michael Niedermayer : avcodec/utils: Ensure 8x8 alignment for ARGO in avcodec_align_dimensio..
>>
>> ...another couple hundred commits from Michael Niedermayer
>>
>> | * cfe614787d 2021/03/21 Derek Buitenhuis : avformat/mov: Fix extended atom size buffer length check
>> | * 7efe57ba11 2021/03/21 James Almer : avformat: remove FF_API_INIT_PACKET from AVStream.attached_pic
>> | * da4d578621 2021/03/20 Michael Niedermayer : Update versions for 4.4
>> * | 5abfeff78a 2021/10/30 ulmus-scott : fix non UTF-8 files (external)
>> * | 4a52936a03 2021/10/30 Klaas de Waal : Update changed streams on PMT update
>> * | f6663afec2 2021/10/30 Peter Bennett : Merge commit 'c67d2a2875' into base4.4
>> |\|
>> | * c67d2a2875 2021/03/20 Michael Niedermayer : Bump Versions before release/4.4 branch
>> | * 17cf309dfa 2021/03/20 Michael Niedermayer : doc/APIchanges: fill in missing fields
>> | * 33a1687bf6 2021/03/20 Michael Niedermayer : avcodec/mpeg4videoenc: Check extradata malloc()
>>
>> ... more
>>
>> Only those commits with asterisk as the first character have the MythTV customizations. All the others (about 335) with Michael Niedermayer and others will give you pure FFmpeg code with none of the MythTV customizations until merged. So I suppose what is needed is to merge at different points within those hundreds of commits, fix the errors and conflicts, and test.
>>
>> Perhaps some sort of rebase instead of merge would have helped. I am not sure how to do that or if it would work. Perhaps another alternative is cherry-pick each commit.
>>
>> The procedure I follow for the ffmpeg update is in the following file in the ffmpeg-resync branch:
>>
>> https://github.com/MythTV/mythtv/blob/devel/ffmpeg-resync/mythtv/external/FFmpeg-sync-instructions.txt
>>
>> Peter
>>
> Peter,
>
> This whole situation is imho usual example of case where downstream code changes potentially introducing regressions.
> This happens not so rare in various projects i'm following.
>
> In such case critical is to have clear visibility of downstream changes - very useful to nail-down particular change being root cause for regression.
> imho best way to do this effectively is to have downstream as:
>
> 4.4 downstream: 4.4 upstream + mythtv downstream changes
>
> instead of
>
> 4.4 downstream: 4.3 downstream + 4.4 upstream back-ports + mythtv downstream changes
>
>
> First model has imho at least following benefits:
> -offers clear view on downstream code changes i.e. for review (including peer review)
> -is almost mandatory for upstreaming
> -needed to properly expose intellectual property (imho mandatory habit in FOSS)
> -makes future rebases much easier (imho)
>
> Second model (i believe current model we are using) has imho following issues (at least for me):
> -very difficult to find root causes introduced at down-streaming. (peer review by i.e. invited 3rd party devs is practically impossible)
> -not addressing potential upstreaming at all
> -practically losses intellectual property info about downstream code
> -more work is needed at rebasinng
> -makes approach with shared FFmpeg practically impossible (i mean common system FFmpeg used by MythTV and other apps i.e. Kodi or mpv ro whatever)(*)
> (shared FFmpeg can help for regressions testing + can improve maintenance by code reuse)
>
>
> btw: some time ago i already proposed above to Mark Kendal for change to model 1 - but received no any reaction/comment on this....
>
> (*) - I already do experiment with Kodi using MythTV FFmpeg: Kodi fails to properly decode video with V4l2_request - even when working Kodi FFmpeg & MythTV FFmepg have exactly the same V4l2_request code....
>
>

Here is a diff showing MythTV FFmpeg changes in the devel/ffmpeg_resync
branch. There are 6277 lines of difference. These are the "mythtv
downstream changes". Applying these changes to the real FFmpeg 4.4.1
gives us the MythTV devel/ffmpeg_resync copy of FFmpeg, per your option
1 above. I don't know if this helps.

https://pastebin.com/cM2NPyFE

FFmpeg has 7479 files, 1809271 lines

MythTV's ffmpeg has 7483 files, 1813951 lines

Peter


_______________________________________________
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 11/16/21 12:51 PM, Peter Bennett wrote:
> Here is a diff showing MythTV FFmpeg changes in the
> devel/ffmpeg_resync branch. There are 6277 lines of difference. These
> are the "mythtv downstream changes". Applying these changes to the
> real FFmpeg 4.4.1 gives us the MythTV devel/ffmpeg_resync copy of
> FFmpeg, per your option 1 above. I don't know if this helps.
I think what Piotr is trying to say is that it is much easier to see
what the changes are and *why* if you rebase the downstream (in this
case MythTV) changes onto the new upstream version.

This also makes applying the changes to future new versions easier,
since you only have to deal with the new upstream changes because the
downstream changes have already been rebased onto a more recent upstream.

I tried to do that, but it doesn't apply cleanly and my attempt to fix
the merge issues ended up with something not identical to the MythTV
version.  (However, I'm not that familiar with git, so I probably did
something wrong.)

clone https://github.com/MythTV/FFmpeg
add as upstream https://github.com/FFmpeg/FFmpeg
rebase origin release/4.4 onto upstream release/4.4

Yes, you can diff the MythTV release/4.4 with the FFmpeg release/4.4,
but that only shows you what, not why.  Git blame might help get the
reasons behind the changes, but that would be rather manual work.

The *why* is extremely important, especially when upstreaming the
changes, which should be the goal.

Regards,
Scott

On Fri, Nov 12, 2021 at 08:39:58PM +0100, Klaas de Waal wrote:
> 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.

Klaas,

Have you tried playing your test content with ffplay, with and without
the MythTV changes? If we're lucky and vanilla ffplay doesn't exhibit
the problem and MythTV ffplay does, that might be the easiest case to
debug.

David
--
David Engel
david@istwok.net
_______________________________________________
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

My second try rebasing worked:
https://github.com/ulmus-scott/FFmpeg/tree/rebase/4.4m

Note the following changes vs
https://github.com/MythTV/FFmpeg/tree/release/4.4 :
two more cherry-picked commits from upstream

removed duplicated entry in libavcodec/codec_desc.c
fixed indentation in two other files

tweaked Klaas' commit message to not confuse GitHub:
https://github.com/ulmus-scott/FFmpeg/commit/77526ccf1dbf62cab94f8b0522b7615a016f9314

dropped two commits and their reversions

Regards,
Scott
_______________________________________________
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

> Wiadomo?? napisana przez Scott Theisen <scott.the.elm@gmail.com> w dniu 17.11.2021, o godz. 04:42:
>
> My second try rebasing worked: https://github.com/ulmus-scott/FFmpeg/tree/rebase/4.4m
>
> Note the following changes vs https://github.com/MythTV/FFmpeg/tree/release/4.4 :
> two more cherry-picked commits from upstream
>
> removed duplicated entry in libavcodec/codec_desc.c
> fixed indentation in two other files
>
> tweaked Klaas' commit message to not confuse GitHub: https://github.com/ulmus-scott/FFmpeg/commit/77526ccf1dbf62cab94f8b0522b7615a016f9314
>
> dropped two commits and their reversions
>
> Regards,
> Scott

Scott,

This is great work!

Now it think we may transform list of current downstream commits into reasonably defined functional commits.

Example functional commits deduced from:
https://github.com/ulmus-scott/FFmpeg/commit/bb39833100571d981302e0203feac6f53dc6ff52

_Just proposal...._

prepare FFMpeg to be internal in MythTV
add MythTV mpegs demuxer
add MHEG support
add CC support
add VBI support
change DVD subtitles handling
fix MPEG 4playback
fix Audio parser
fix NUV playback
fix ATSC captions
fix DVD PCM playback
fix DVD PGS subtitles
.......

We may discuss with git commit comment facility in each hunk regarding: what & why; then after this brain learning invent best name of functional commit for hunk; then group all relevant hunks into such functional commit.
This is boring reverse engineering - but imho rather unavoidable for upstreaming & have shared FFmpeg goals.


General assumptions:

Every functional commit:
-will be set of cherry-picked chunks from multiple current commits
-prepared to apply clean and allows to build at least partially working mythtv (for testing, regressions etc)
-is responsible for atomic functionality

this will help us to:
-easier find regression root causing commit (i.e. breaking NV decode mentioned by Klaas)
-be useful in future for regression & cross-regression testing

Note:
we have current multiple commits with spread multiple hunks each and we want to sort hunks into new list of functional commits.
key for me seems to be proper definition of functional commits.

Sorting current hunks in to commits we can do i.e.:
1.generate patch per each current commit
2.sort & move relevant hunks from p.1 patches into new functional patches (getting 1st functional patch and scan all relevant hunks and put them into patch; compile; test; repeat)
3.apply functional patch on upstream ffmpeg4.4 tree
4.check: after each functional commit we should 100% the same codebase between current 4.4 downstream & 4.4 upstream with functional patches
5.commit p.4 in git if OK

maybe this sounds crazy - but afaik git not allows to selectively move parts of commits between commit1 and commit2 (as commits are atomic).

or i'm wrong here?





_______________________________________________
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, 17 Nov 2021 at 18:51, Piotr Oniszczuk <piotr.oniszczuk@gmail.com>
wrote:

>
>
> > Wiadomo?? napisana przez Scott Theisen <scott.the.elm@gmail.com> w dniu
> 17.11.2021, o godz. 04:42:
> >
> > My second try rebasing worked:
> https://github.com/ulmus-scott/FFmpeg/tree/rebase/4.4m
> >
> > Note the following changes vs
> https://github.com/MythTV/FFmpeg/tree/release/4.4 :
> > two more cherry-picked commits from upstream
> >
> > removed duplicated entry in libavcodec/codec_desc.c
> > fixed indentation in two other files
> >
> > tweaked Klaas' commit message to not confuse GitHub:
> https://github.com/ulmus-scott/FFmpeg/commit/77526ccf1dbf62cab94f8b0522b7615a016f9314
> >
> > dropped two commits and their reversions
> >
> > Regards,
> > Scott
>
> Scott,
>
> This is great work!
>
> Now it think we may transform list of current downstream commits into
> reasonably defined functional commits.
>
> Example functional commits deduced from:
>
> https://github.com/ulmus-scott/FFmpeg/commit/bb39833100571d981302e0203feac6f53dc6ff52
>
> _Just proposal...._
>
> prepare FFMpeg to be internal in MythTV
> add MythTV mpegs demuxer
> add MHEG support
> add CC support
> add VBI support
> change DVD subtitles handling
> fix MPEG 4playback
> fix Audio parser
> fix NUV playback
> fix ATSC captions
> fix DVD PCM playback
> fix DVD PGS subtitles
> .......
>
> We may discuss with git commit comment facility in each hunk regarding:
> what & why; then after this brain learning invent best name of functional
> commit for hunk; then group all relevant hunks into such functional commit.
> This is boring reverse engineering - but imho rather unavoidable for
> upstreaming & have shared FFmpeg goals.
>
>
> General assumptions:
>
> Every functional commit:
> -will be set of cherry-picked chunks from multiple current commits
> -prepared to apply clean and allows to build at least partially working
> mythtv (for testing, regressions etc)
> -is responsible for atomic functionality
>
> this will help us to:
> -easier find regression root causing commit (i.e. breaking NV decode
> mentioned by Klaas)
> -be useful in future for regression & cross-regression testing
>
> Note:
> we have current multiple commits with spread multiple hunks each and we
> want to sort hunks into new list of functional commits.
> key for me seems to be proper definition of functional commits.
>
> Sorting current hunks in to commits we can do i.e.:
> 1.generate patch per each current commit
> 2.sort & move relevant hunks from p.1 patches into new functional patches
> (getting 1st functional patch and scan all relevant hunks and put them into
> patch; compile; test; repeat)
> 3.apply functional patch on upstream ffmpeg4.4 tree
> 4.check: after each functional commit we should 100% the same codebase
> between current 4.4 downstream & 4.4 upstream with functional patches
> 5.commit p.4 in git if OK
>
> maybe this sounds crazy - but afaik git not allows to selectively move
> parts of commits between commit1 and commit2 (as commits are atomic).
>
> or i'm wrong here?
>
>
>
>
About

> Have you tried playing your test content with ffplay, with and without
> the MythTV changes? If we're lucky and vanilla ffplay doesn't exhibit
> the problem and MythTV ffplay does, that might be the easiest case to
> debug.


The ffplay from Fedora 35 plays all teletext pages as a video sequence....
with possible a video backdrop but that is difficult to see.
The mythffplay from current master plays OK, both the start and the
skipping.
But more interesting is that mythffplay from the devel/ffmpeg-resync branch
also plays OK, both the start and the skipping.

As the mythtvffplay is linked to the MythTV versions of the ffmpeg
libraries this suggests that the issue is not caused by the MythTV
modifications to ffmpeg but by differences on how the application (ffplay
vs. mythfrontend) does start playback.

Another observation is that, with the devel/ffmpeg-resync branch, the
behavior is different with the original ffmpeg demuxer vs. the mythtv
demuxer.
With the mythtv demuxer both the initial playback start and the restart
after skipping back to the start does show the blocking artifacts.
With the ffmpeg demuxer (as selected with the mythfrontend setup) the
initial playback start does show the blocking artifacts but skipping back
to the start gives OK playback. This then does suggest that (another) good
look at the demuxers could be useful.

As said, if all ffmpeg commits since master are in the mythtv commit
history then it is possible to do a git bisect which is easier than doing a
full debug on ffmpeg.
I did try to create a source tree with all the individual ffmpeg commits
reapplied to the master tree. This did work for a few patches but then
failed due to patch ordering which is decidedly non-linear but more
tree-like as indicated by Peter. I might have been more successful with
this if I did comprehend Peter's merging procedure.
It might be better for mythtv master to sync to a specific commit in ffmpeg
master instead of syncing to the end point of a branch such as 4.4.1.
If we would do that it would be easier to upgrade to newer version of
ffmpeg so that we can do that every month or so. This would reduce the
search space when there is an issue and it would be feasible to create a
mythtv+ffmpeg source tree with all commits that can be used for bisecting.

I intend to have a look at the start-of-file-playback code of ffplay vs.
mythfrontend one of these days.

Klaas.

On 11/18/21 1:08 PM, Klaas de Waal wrote:
> The ffplay from Fedora 35 plays all teletext pages as a video
> sequence.... with possible a video backdrop but that is difficult to see.
> The mythffplay from current master plays OK, both the start and the
> skipping.
> But more interesting is that mythffplay from the devel/ffmpeg-resync
> branch also plays OK, both the start and the skipping.
>
Are you able to make sure that ffplay and mythffplay are using vdpau? I
suspect they may not be using any hardware acceleration. MythTV also
plays fine with no hardware acceleration. ffplay does not support the
-hwaccel option that is available with ffmpeg.

You can add -sst 0 option to ffplay to prevent the videotext from showing.

Peter


_______________________________________________
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 11/18/21 3:12 PM, Peter Bennett wrote:
>
> On 11/18/21 1:08 PM, Klaas de Waal wrote:
>> The ffplay from Fedora 35 plays all teletext pages as a video
>> sequence.... with possible a video backdrop but that is difficult to
>> see.
>> The mythffplay from current master plays OK, both the start and the
>> skipping.
>> But more interesting is that mythffplay from the devel/ffmpeg-resync
>> branch also plays OK, both the start and the skipping.
>>
> Are you able to make sure that ffplay and mythffplay are using vdpau?
> I suspect they may not be using any hardware acceleration. MythTV also
> plays fine with no hardware acceleration. ffplay does not support the
> -hwaccel option that is available with ffmpeg.
>
> You can add -sst 0 option to ffplay to prevent the videotext from
> showing.
>
> Peter
>
>
An old link, but maybe still correct:

https://ffmpeg-user.ffmpeg.narkive.com/TpH64Voh/ffplay-and-vdpau

https://lists.ffmpeg.org/pipermail/ffmpeg-user/2012-July/008121.html


_______________________________________________
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

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)



_______________________________________________
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 Thu, 18 Nov 2021 at 21:40, Piotr Oniszczuk <piotr.oniszczuk@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 <pb.mythtv@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 <piotr.oniszczuk@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.

On 19/11/2021 20:34, Klaas de Waal wrote:
>
>
> On Thu, 18 Nov 2021 at 21:40, Piotr Oniszczuk <piotr.oniszczuk@gmail.com
> <mailto:piotr.oniszczuk@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@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@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

_______________________________________________
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

tl;dr Also blocking artifacts when skipping with mpv when VDPAU is used.
Blocking artifacts with vlc when using VDPAU but also when NOT using VDPAU.
Blocking artifacts with mplayer.
Failed to create a MythTV with an unmodified FFmpeg tree.

And this is the long version....

I have been doing some more tests with mpv and this time with various
options.
The file used for testing, tweevoortwaalf-ffmpeg.ts, has been shared in
this thread.
Note that this file is the first 100Mbyte of a mythtv recording and it is
representative of what is here on the local cable network, it is not a
sequence specially crafted to test decoders.

This plays OK:
$ mpv tweevoortwaalf-ffmpeg.ts
$ mpv -vo vdpau tweevoortwaalf-ffmpeg.ts
$ mpv -vo=gpu tweevoortwaalf_ffmpeg.ts
$ mpv --hwdec=vdpau tweevoortwaalf_ffmpeg.ts
$ mpv -vo=gpu --hwdec=vdpau tweevoortwaalf_ffmpeg.ts

This gives blocking artifacts with skipping:
$ mpv -vo=vdpau --hwdec=vdpau tweevoortwaalf_ffmpeg.ts
$ mpv --vo=gpu --hwdec=vdpau-copy tweevoortwaalf_ffmpeg.ts

This is the mpv version used, as present in Fedora 35.
[klaas@modu videos]$ mpv -version
mpv 0.34.0 Copyright © 2000-2021 mpv/MPlayer/mplayer2 projects
built on UNKNOWN
FFmpeg library versions:
libavutil 56.70.100
libavcodec 58.134.100
libavformat 58.76.100
libswscale 5.9.100
libavfilter 7.110.100
libswresample 3.9.100
FFmpeg version: 4.4.1

This plays correct but while it uses Nvidia hardware it does NOT use VDPAU
as pointed out by Peter:
$ ffplay -sst 0 -vcodec h264_cuvid tweevoortwaalf_ffmpeg.ts

But interesting: playback with VLC also gives blocking artifacts!
VLC uses VDPAU by default as shown here:
[klaas@modu videos]$ vlc tweevoortwaalf_ffmpeg.ts
VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2)
[0000560ed8f70b70] main libvlc: Running vlc with the default interface. Use
'cvlc' to use vlc without interface.
[00007fd348005720] gl gl: Initialized libplacebo v4.157.0 (API v157)
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_12
libva info: va_openDriver() returns 0
[00007fd348005720] glconv_vaapi_x11 gl error: vaCreateSurfaces: attribute
not supported
[00007fd344077100] main video output error: video output creation failed
[00007fd354c10f90] main decoder error: failed to create video output
[00007fd3484ada50] gl gl: Initialized libplacebo v4.157.0 (API v157)
[00007fd354c10f90] avcodec decoder: Using NVIDIA VDPAU Driver Shared
Library 495.44 Fri Oct 22 06:03:50 UTC 2021 for hardware decoding

Further complicating the issue is that when playing the same clip on
another system with Intel built-in graphics, VLC also gives the blocking
artifacts.

Next test with the mplayer: also blocking artifacts when skipping for all
tested video output options (vdpau, xv, x11, gl).
[klaas@modu videos]$ mplayer tweevoortwaalf_ffmpeg.ts
MPlayer SVN-r38302-11 (C) 2000-2021 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote
control.

Playing tweevoortwaalf_ffmpeg.ts.
libavformat version 58.76.100 (external)
TS file format detected.
VIDEO H264(pid=2301) AUDIO MPA(pid=2311) SUB Teletext(pid=2401) PROGRAM N.
1
FPS seems to be: 25.000000
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 58.134.100 (external)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Load subtitles in ./
==========================================================================
Requested audio codec family [mpg123] (afm=mpg123) not available.
Enable it at compilation.
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, floatle, 256.0 kbit/8.33% (ratio: 32000->384000)
Selected audio codec: [ffmp2float] afm: ffmpeg (FFmpeg MPEG layer-1 and
layer-2 audio)
==========================================================================
AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
Bad stream state, please report as bug!
Bad stream state, please report as bug!
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 1920x1080 => 1920x1080 Planar YV12
A:71555.4 V:71556.4 A-V: -0.948 ct: 0.000 2/ 2 ??% ??% ??,?% 0 0
Bad stream state, please report as bug!
Bad stream state, please report as bug!
Bad stream state, please report as bug!
Bad stream state, please report as bug!


It looks like skipping correctly in these transport streams with H264 1080
interlaced is not trivial.
However, mythfrontend has been skipping correctly for the last 15 years up
to and including the current master.
So it should be feasible to get this working also with the latest FFmpeg.

In order to start somewhere I have replaced, in a copy of the current
master, the FFmpeg tree with the latest FFmpeg master and then hacked away
in the MythTV code so that it could work with an (almost) unmodified ffmpeg
tree.
The great plan behind this is:
- If it shows blocking behaviour then bisect the ffmpeg from the latest
version to something that is close to what is now in master. This is why I
want ffmpeg master because there is then a linear sequence of commits
instead of a tree.
- If it does NOT show blocking behaviour then add the MythTV changes one by
one and check for blocking behaviour.

However, while compilation is now OK, linking fails with unresolved symbols.
These are symbols that do show up as global in the object file but then are
local when included in the .so file.
Example, for a file that I did add to libavcodec (that is the "almost"
unmodified):

[klaas@modu libavcodec]$ nm libmythavcodec.so | grep ff_codec_type
00000000006b4200 t ff_codec_type_string
[klaas@modu libavcodec]$ nm utils-mythtv.o | grep ff_codec_type
0000000000000940 T ff_codec_type_string
[klaas@modu libavcodec]$ readelf -s utils-mythtv.o | grep ff_codec_type
181: 0000000000000940 128 FUNC GLOBAL DEFAULT 1
ff_codec_type_string
[klaas@modu libavcodec]$ readelf -s libmythavcodec.so | grep ff_codec_type
20731: 00000000006b4200 128 FUNC LOCAL DEFAULT 12
ff_codec_type_string

Note that there are more unresolved who are not from a file that I added.
This is the complete list from linking programs/mythavtest:
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ffurl_close'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ffurl_seek'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ffurl_open'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ff_ue_golomb_vlc_code'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ffurl_write'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ffurl_read'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ff_se_golomb_vlc_code'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ff_read_frame_flush'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ff_codec_type_string'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ffurl_size'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ff_golomb_vlc_len'
/usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference to
`ff_codec_id_string'
The two ff_codec_.. functions are in file avcodec/utils-mythtv.c and they
can be moved to outside FFmpeg.
I would have done that if it were the only unresolved symbols.

This is basically where the project is currently halted....

Klaas.

> Wiadomo?? napisana przez Klaas de Waal <klaas.de.waal@gmail.com> w dniu 22.11.2021, o godz. 19:07:
>
>
> Further complicating the issue is that when playing the same clip on another system with Intel built-in graphics, VLC also gives the blocking artifacts.
>

1: so it looks to me blocking artefacts are not only VDPAU thing.
2: it looks to me other players also have issue blocking artefacts (VLC)

> Next test with the mplayer: also blocking artifacts when skipping for all tested video output options (vdpau, xv, x11, gl).

3: so other players also have issue blocking artefacts (mplayer)


so i conclude:

it IS NOT that myth downstream changes are regressing to blocking artefacts

it IS that myth downstream changes allows to play WITHOUT blocking artefacts.

If you agree wit me then imho best strategy might be:

-have repo where we can apply myth downstream changes over ffmpeg upstream (Scott work seems to really nice work here)

-consider to for to test branch with minimized downstream changes (just to minimise potential conflicts at rebasing in next steeps)

-start with rebase to working ffmpeg upstream (4.3.2 i believe). (for double check that we have myth downstream fixing artefacts working for us)

-Incrementally rebase to newer upstream code until myth downstream stops playing without artefacts. We can do this i.e. with binary search algo starting in middle upstream commit between 4.3.2 and 4.4.1.

-after identifying upstream ffmpeg change which breaks - we can see what will be better: revert change in upstream or modify downstream to adapt






_______________________________________________
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