Mailing List Archive

HVEC frame counting broken
I just upgraded from 39b850f1a9 to 06da3119d5 and discovered that frame
counting is now broken for ffmpeg/nvenc encoded HVEC. The OSD indicates
that the shows are twice as long as they really are.

This weekend I will do a bisec to figure out which commit did the damage,
unless someone else already knows?

Thanks,

John
Re: HVEC frame counting broken [ In reply to ]
On Fri, Sep 23, 2022 at 4:32 PM John P Poet <jppoet@gmail.com> wrote:

> I just upgraded from 39b850f1a9 to 06da3119d5 and discovered that frame
> counting is now broken for ffmpeg/nvenc encoded HVEC. The OSD indicates
> that the shows are twice as long as they really are.
>
> This weekend I will do a bisec to figure out which commit did the damage,
> unless someone else already knows?
>

Sorry. Make that 26b2e76ae to 06da3119d5.

John
Re: HVEC frame counting broken [ In reply to ]
On Fri, Sep 23, 2022 at 04:38:19PM -0600, John P Poet wrote:
> On Fri, Sep 23, 2022 at 4:32 PM John P Poet <jppoet@gmail.com> wrote:
>
> > I just upgraded from 39b850f1a9 to 06da3119d5 and discovered that frame
> > counting is now broken for ffmpeg/nvenc encoded HVEC. The OSD indicates
> > that the shows are twice as long as they really are.
> >
> > This weekend I will do a bisec to figure out which commit did the damage,
> > unless someone else already knows?
> >
>
> Sorry. Make that 26b2e76ae to 06da3119d5.

It's probably the very, recent, ffmpeg merge.

While you're in there, though, would you mind looking into the
long-standing issue with mythcommflag --rebuild not working on HEVC
encoded files, or at least those encoded by HandBarke? :)

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
Re: HVEC frame counting broken [ In reply to ]
On 9/23/22 18:59, David Engel wrote:
> On Fri, Sep 23, 2022 at 04:38:19PM -0600, John P Poet wrote:
>> On Fri, Sep 23, 2022 at 4:32 PM John P Poet <jppoet@gmail.com> wrote:
>>
>>> I just upgraded from 39b850f1a9 to 06da3119d5 and discovered that frame
>>> counting is now broken for ffmpeg/nvenc encoded HVEC. The OSD indicates
>>> that the shows are twice as long as they really are.
>>>
>>> This weekend I will do a bisec to figure out which commit did the damage,
>>> unless someone else already knows?
>>>
>> Sorry. Make that 26b2e76ae to 06da3119d5.
> It's probably the very, recent, ffmpeg merge.
>
> While you're in there, though, would you mind looking into the
> long-standing issue with mythcommflag --rebuild not working on HEVC
> encoded files, or at least those encoded by HandBarke? :)

A note on bisecting the recent FFmpeg merge:
a1868defe9c48c5ca53e1c5d26010a19ebd7db13..753a94ccb7a39ef66c6f8591e5784bf08a1b002e
wont compile (inclusive..exclusive) fully because of how I split the
commits.

My harmonization of libavcodec/mpegts-mythtv.c is also in the range you
gave.  While each commit compiles, I didn't test functionality of each
commit.  But, even if the container is an MPEG-TS, I would also suspect
the new version of FFmpeg.

Could be related to (HEVC):
Playback of DVB recordings shows displayed time doubled · Issue #548 ·
MythTV/mythtv · GitHub
https://github.com/MythTV/mythtv/issues/548
?

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
Re: HVEC frame counting broken [ In reply to ]
On Fri, Sep 23, 2022 at 6:31 PM Scott Theisen <scott.the.elm@gmail.com>
wrote:

> On 9/23/22 18:59, David Engel wrote:
> > On Fri, Sep 23, 2022 at 04:38:19PM -0600, John P Poet wrote:
> >> On Fri, Sep 23, 2022 at 4:32 PM John P Poet <jppoet@gmail.com> wrote:
> >>
> >>> I just upgraded from 39b850f1a9 to 06da3119d5 and discovered that frame
> >>> counting is now broken for ffmpeg/nvenc encoded HVEC. The OSD indicates
> >>> that the shows are twice as long as they really are.
> >>>
> >>> This weekend I will do a bisec to figure out which commit did the
> damage,
> >>> unless someone else already knows?
> >>>
> >> Sorry. Make that 26b2e76ae to 06da3119d5.
> > It's probably the very, recent, ffmpeg merge.
> >
> > While you're in there, though, would you mind looking into the
> > long-standing issue with mythcommflag --rebuild not working on HEVC
> > encoded files, or at least those encoded by HandBarke? :)
>
> A note on bisecting the recent FFmpeg merge:
> a1868defe9c48c5ca53e1c5d26010a19ebd7db13..753a94ccb7a39ef66c6f8591e5784bf08a1b002e
>
> wont compile (inclusive..exclusive) fully because of how I split the
> commits.
>
> My harmonization of libavcodec/mpegts-mythtv.c is also in the range you
> gave. While each commit compiles, I didn't test functionality of each
> commit. But, even if the container is an MPEG-TS, I would also suspect
> the new version of FFmpeg.
>
> Could be related to (HEVC):
> Playback of DVB recordings shows displayed time doubled · Issue #548 ·
> MythTV/mythtv · GitHub
> https://github.com/MythTV/mythtv/issues/548
> ?
>
> Regards,
>
> Scott
>

Thank you Scott.

What is bizaar is that I went back to 39b850f1a9 and it was still doubling.
I could have sworn that was the commit I was running before! I ended up
jumping back and back and back until I randomly found 31ee7f9e64 to work
correctly. So, now I have to say the problem occured somewhere between
31ee7f9e64 and 3e802f9075. I will try and narrow it down tomorrow.

John
Re: HVEC frame counting broken [ In reply to ]
On Fri, Sep 23, 2022 at 7:02 PM John P Poet <jppoet@gmail.com> wrote:

> On Fri, Sep 23, 2022 at 6:31 PM Scott Theisen <scott.the.elm@gmail.com>
> wrote:
>
>> On 9/23/22 18:59, David Engel wrote:
>> > On Fri, Sep 23, 2022 at 04:38:19PM -0600, John P Poet wrote:
>> >> On Fri, Sep 23, 2022 at 4:32 PM John P Poet <jppoet@gmail.com> wrote:
>> >>
>> >>> I just upgraded from 39b850f1a9 to 06da3119d5 and discovered that
>> frame
>> >>> counting is now broken for ffmpeg/nvenc encoded HVEC. The OSD
>> indicates
>> >>> that the shows are twice as long as they really are.
>> >>>
>> >>> This weekend I will do a bisec to figure out which commit did the
>> damage,
>> >>> unless someone else already knows?
>> >>>
>> >> Sorry. Make that 26b2e76ae to 06da3119d5.
>> > It's probably the very, recent, ffmpeg merge.
>> >
>> > While you're in there, though, would you mind looking into the
>> > long-standing issue with mythcommflag --rebuild not working on HEVC
>> > encoded files, or at least those encoded by HandBarke? :)
>>
>> A note on bisecting the recent FFmpeg merge:
>> a1868defe9c48c5ca53e1c5d26010a19ebd7db13..753a94ccb7a39ef66c6f8591e5784bf08a1b002e
>>
>> wont compile (inclusive..exclusive) fully because of how I split the
>> commits.
>>
>> My harmonization of libavcodec/mpegts-mythtv.c is also in the range you
>> gave. While each commit compiles, I didn't test functionality of each
>> commit. But, even if the container is an MPEG-TS, I would also suspect
>> the new version of FFmpeg.
>>
>> Could be related to (HEVC):
>> Playback of DVB recordings shows displayed time doubled · Issue #548 ·
>> MythTV/mythtv · GitHub
>> https://github.com/MythTV/mythtv/issues/548
>> ?
>>
>> Regards,
>>
>> Scott
>>
>
> Thank you Scott.
>
> What is bizaar is that I went back to 39b850f1a9 and it was still
> doubling. I could have sworn that was the commit I was running before! I
> ended up jumping back and back and back until I randomly found 31ee7f9e64
> to work correctly. So, now I have to say the problem occured somewhere
> between 31ee7f9e64 and 3e802f9075. I will try and narrow it down tomorrow.
>

Okay, so I was running 39b850f1a9 on my production machine and 26b2e76ae
on my development machine. I had not noticed the issue on my dev machine.

The problem does seem to be between 31ee7f9e64 and 3e802f9075. Looking at
the commits in that range, 40fb3cd09d and db93047399 seem like
possibilities. My production machine is now recording stuff for the evening
so I will test more tomorrow.

John
Re: HVEC frame counting broken [ In reply to ]
On 24/09/2022 02:18, John P Poet wrote:
> On Fri, Sep 23, 2022 at 7:02 PM John P Poet <jppoet@gmail.com
> <mailto:jppoet@gmail.com>> wrote:
>
> On Fri, Sep 23, 2022 at 6:31 PM Scott Theisen
> <scott.the.elm@gmail.com <mailto:scott.the.elm@gmail.com>> wrote:
>
> On 9/23/22 18:59, David Engel wrote:
> > On Fri, Sep 23, 2022 at 04:38:19PM -0600, John P Poet wrote:
> >> On Fri, Sep 23, 2022 at 4:32 PM John P Poet
> <jppoet@gmail.com <mailto:jppoet@gmail.com>> wrote:
> >>
> >>> I just upgraded from 39b850f1a9 to 06da3119d5 and
> discovered that frame
> >>> counting is now broken for ffmpeg/nvenc encoded HVEC. The
> OSD indicates
> >>> that the shows are twice as long as they really are.
> >>>
> >>> This weekend I will do a bisec to figure out which commit
> did the damage,
> >>> unless someone else already knows?
> >>>
> >> Sorry. Make that  26b2e76ae to 06da3119d5.
> > It's probably the very, recent, ffmpeg merge.
> >
> > While you're in there, though, would you mind looking into the
> > long-standing issue with mythcommflag --rebuild not working
> on HEVC
> > encoded files, or at least those encoded by HandBarke? :)
>
> A note on bisecting the recent FFmpeg merge:
> a1868defe9c48c5ca53e1c5d26010a19ebd7db13..753a94ccb7a39ef66c6f8591e5784bf08a1b002e
>
> wont compile (inclusive..exclusive) fully because of how I split
> the
> commits.
>
> My harmonization of libavcodec/mpegts-mythtv.c is also in the
> range you
> gave.  While each commit compiles, I didn't test functionality
> of each
> commit.  But, even if the container is an MPEG-TS, I would also
> suspect
> the new version of FFmpeg.
>
> Could be related to (HEVC):
> Playback of DVB recordings shows displayed time doubled · Issue
> #548 ·
> MythTV/mythtv · GitHub
> https://github.com/MythTV/mythtv/issues/548
> <https://github.com/MythTV/mythtv/issues/548>
> ?
>
> Regards,
>
> Scott
>
>
> Thank you Scott.
>
> What is bizaar is that I went back to 39b850f1a9 and it was still
> doubling. I could have sworn that was the commit I was running
> before! I ended up jumping back and back and back until I randomly
> found 31ee7f9e64 to work correctly. So, now I have to say the
> problem occured somewhere between 31ee7f9e64 and 3e802f9075. I will
> try and narrow it down tomorrow.
>
>
> Okay, so I was running  39b850f1a9 on my production machine and
> 26b2e76ae on my development machine. I had not noticed the issue on my
> dev machine.
>
> The problem does seem to be between 31ee7f9e64 and 3e802f9075. Looking
> at the commits in that range, 40fb3cd09d and db93047399 seem like
> possibilities. My production machine is now recording stuff for the
> evening so I will test more tomorrow.
>
> John

Issue #548 was reported as being years-old for some HEVC recordings. I
had similar issues with just one of six DVB-T (mpeg2ts) multiplexes, now
fixed by PR#610.

mythcommflag --rebuild gave good frame counts for me, but gigem says it
doesn't work with handbrake's HEVC encoding.

It looks to me as if ffmpeg doesn't understand 'with field pictures'
encoding.

John (Pilkington)
_______________________________________________
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
Re: HVEC frame counting broken [ In reply to ]
On Sat, Sep 24, 2022 at 3:38 AM John Pilkington <johnpilk222@gmail.com>
wrote:

> On 24/09/2022 02:18, John P Poet wrote:
> > On Fri, Sep 23, 2022 at 7:02 PM John P Poet <jppoet@gmail.com
> > <mailto:jppoet@gmail.com>> wrote:
> >
> > On Fri, Sep 23, 2022 at 6:31 PM Scott Theisen
> > <scott.the.elm@gmail.com <mailto:scott.the.elm@gmail.com>> wrote:
> >
> > On 9/23/22 18:59, David Engel wrote:
> > > On Fri, Sep 23, 2022 at 04:38:19PM -0600, John P Poet wrote:
> > >> On Fri, Sep 23, 2022 at 4:32 PM John P Poet
> > <jppoet@gmail.com <mailto:jppoet@gmail.com>> wrote:
> > >>
> > >>> I just upgraded from 39b850f1a9 to 06da3119d5 and
> > discovered that frame
> > >>> counting is now broken for ffmpeg/nvenc encoded HVEC. The
> > OSD indicates
> > >>> that the shows are twice as long as they really are.
> > >>>
> > >>> This weekend I will do a bisec to figure out which commit
> > did the damage,
> > >>> unless someone else already knows?
> > >>>
> > >> Sorry. Make that 26b2e76ae to 06da3119d5.
> > > It's probably the very, recent, ffmpeg merge.
> > >
> > > While you're in there, though, would you mind looking into the
> > > long-standing issue with mythcommflag --rebuild not working
> > on HEVC
> > > encoded files, or at least those encoded by HandBarke? :)
> >
> > A note on bisecting the recent FFmpeg merge:
> >
> a1868defe9c48c5ca53e1c5d26010a19ebd7db13..753a94ccb7a39ef66c6f8591e5784bf08a1b002e
> >
> > wont compile (inclusive..exclusive) fully because of how I split
> > the
> > commits.
> >
> > My harmonization of libavcodec/mpegts-mythtv.c is also in the
> > range you
> > gave. While each commit compiles, I didn't test functionality
> > of each
> > commit. But, even if the container is an MPEG-TS, I would also
> > suspect
> > the new version of FFmpeg.
> >
> > Could be related to (HEVC):
> > Playback of DVB recordings shows displayed time doubled · Issue
> > #548 ·
> > MythTV/mythtv · GitHub
> > https://github.com/MythTV/mythtv/issues/548
> > <https://github.com/MythTV/mythtv/issues/548>
> > ?
> >
> > Regards,
> >
> > Scott
> >
> >
> > Thank you Scott.
> >
> > What is bizaar is that I went back to 39b850f1a9 and it was still
> > doubling. I could have sworn that was the commit I was running
> > before! I ended up jumping back and back and back until I randomly
> > found 31ee7f9e64 to work correctly. So, now I have to say the
> > problem occured somewhere between 31ee7f9e64 and 3e802f9075. I will
> > try and narrow it down tomorrow.
> >
> >
> > Okay, so I was running 39b850f1a9 on my production machine and
> > 26b2e76ae on my development machine. I had not noticed the issue on my
> > dev machine.
> >
> > The problem does seem to be between 31ee7f9e64 and 3e802f9075. Looking
> > at the commits in that range, 40fb3cd09d and db93047399 seem like
> > possibilities. My production machine is now recording stuff for the
> > evening so I will test more tomorrow.
> >
> > John
>
> Issue #548 was reported as being years-old for some HEVC recordings. I
> had similar issues with just one of six DVB-T (mpeg2ts) multiplexes, now
> fixed by PR#610.
>
> mythcommflag --rebuild gave good frame counts for me, but gigem says it
> doesn't work with handbrake's HEVC encoding.
>
> It looks to me as if ffmpeg doesn't understand 'with field pictures'
> encoding.
>

Doing a git bisect on my 10 year old production mythbackend machine is a
bit painful, but the result is that 7b2ac1eeb5 is the culprit. I see that
a6e1128e0f2 fixes a problem caused by 7b2ac1eeb5 but not this one. I will
work on narrowing down the problem.

John
Re: HVEC frame counting broken [ In reply to ]
On Sat, Sep 24, 2022 at 3:35 PM John P Poet <jppoet@gmail.com> wrote:

> On Sat, Sep 24, 2022 at 3:38 AM John Pilkington <johnpilk222@gmail.com>
> wrote:
>
>> On 24/09/2022 02:18, John P Poet wrote:
>> > On Fri, Sep 23, 2022 at 7:02 PM John P Poet <jppoet@gmail.com
>> > <mailto:jppoet@gmail.com>> wrote:
>> >
>> > On Fri, Sep 23, 2022 at 6:31 PM Scott Theisen
>> > <scott.the.elm@gmail.com <mailto:scott.the.elm@gmail.com>> wrote:
>> >
>> > On 9/23/22 18:59, David Engel wrote:
>> > > On Fri, Sep 23, 2022 at 04:38:19PM -0600, John P Poet wrote:
>> > >> On Fri, Sep 23, 2022 at 4:32 PM John P Poet
>> > <jppoet@gmail.com <mailto:jppoet@gmail.com>> wrote:
>> > >>
>> > >>> I just upgraded from 39b850f1a9 to 06da3119d5 and
>> > discovered that frame
>> > >>> counting is now broken for ffmpeg/nvenc encoded HVEC. The
>> > OSD indicates
>> > >>> that the shows are twice as long as they really are.
>> > >>>
>> > >>> This weekend I will do a bisec to figure out which commit
>> > did the damage,
>> > >>> unless someone else already knows?
>> > >>>
>> > >> Sorry. Make that 26b2e76ae to 06da3119d5.
>> > > It's probably the very, recent, ffmpeg merge.
>> > >
>> > > While you're in there, though, would you mind looking into
>> the
>> > > long-standing issue with mythcommflag --rebuild not working
>> > on HEVC
>> > > encoded files, or at least those encoded by HandBarke? :)
>> >
>> > A note on bisecting the recent FFmpeg merge:
>> >
>> a1868defe9c48c5ca53e1c5d26010a19ebd7db13..753a94ccb7a39ef66c6f8591e5784bf08a1b002e
>> >
>> > wont compile (inclusive..exclusive) fully because of how I split
>> > the
>> > commits.
>> >
>> > My harmonization of libavcodec/mpegts-mythtv.c is also in the
>> > range you
>> > gave. While each commit compiles, I didn't test functionality
>> > of each
>> > commit. But, even if the container is an MPEG-TS, I would also
>> > suspect
>> > the new version of FFmpeg.
>> >
>> > Could be related to (HEVC):
>> > Playback of DVB recordings shows displayed time doubled · Issue
>> > #548 ·
>> > MythTV/mythtv · GitHub
>> > https://github.com/MythTV/mythtv/issues/548
>> > <https://github.com/MythTV/mythtv/issues/548>
>> > ?
>> >
>> > Regards,
>> >
>> > Scott
>> >
>> >
>> > Thank you Scott.
>> >
>> > What is bizaar is that I went back to 39b850f1a9 and it was still
>> > doubling. I could have sworn that was the commit I was running
>> > before! I ended up jumping back and back and back until I randomly
>> > found 31ee7f9e64 to work correctly. So, now I have to say the
>> > problem occured somewhere between 31ee7f9e64 and 3e802f9075. I will
>> > try and narrow it down tomorrow.
>> >
>> >
>> > Okay, so I was running 39b850f1a9 on my production machine and
>> > 26b2e76ae on my development machine. I had not noticed the issue on my
>> > dev machine.
>> >
>> > The problem does seem to be between 31ee7f9e64 and 3e802f9075. Looking
>> > at the commits in that range, 40fb3cd09d and db93047399 seem like
>> > possibilities. My production machine is now recording stuff for the
>> > evening so I will test more tomorrow.
>> >
>> > John
>>
>> Issue #548 was reported as being years-old for some HEVC recordings. I
>> had similar issues with just one of six DVB-T (mpeg2ts) multiplexes, now
>> fixed by PR#610.
>>
>> mythcommflag --rebuild gave good frame counts for me, but gigem says it
>> doesn't work with handbrake's HEVC encoding.
>>
>> It looks to me as if ffmpeg doesn't understand 'with field pictures'
>> encoding.
>>
>
> Doing a git bisect on my 10 year old production mythbackend machine is a
> bit painful, but the result is that 7b2ac1eeb5 is the culprit. I see that
> a6e1128e0f2 fixes a problem caused by 7b2ac1eeb5 but not this one. I will
> work on narrowing down the problem.
>

HEVCParser::parseSPS is seriously broken with 7b2ac1eeb5. It does not even
get the sps_id correct, let alone width, height or timescale. I have spent
the last several hours trying to figure out exactly where the parsing goes
wrong but have not tracked it down yet.

John
Re: HVEC frame counting broken [ In reply to ]
On Sat, Sep 24, 2022 at 7:01 PM John P Poet <jppoet@gmail.com> wrote:

> On Sat, Sep 24, 2022 at 3:35 PM John P Poet <jppoet@gmail.com> wrote:
>
>> On Sat, Sep 24, 2022 at 3:38 AM John Pilkington <johnpilk222@gmail.com>
>> wrote:
>>
>>> On 24/09/2022 02:18, John P Poet wrote:
>>> > On Fri, Sep 23, 2022 at 7:02 PM John P Poet <jppoet@gmail.com
>>> > <mailto:jppoet@gmail.com>> wrote:
>>> >
>>> > On Fri, Sep 23, 2022 at 6:31 PM Scott Theisen
>>> > <scott.the.elm@gmail.com <mailto:scott.the.elm@gmail.com>> wrote:
>>> >
>>> > On 9/23/22 18:59, David Engel wrote:
>>> > > On Fri, Sep 23, 2022 at 04:38:19PM -0600, John P Poet wrote:
>>> > >> On Fri, Sep 23, 2022 at 4:32 PM John P Poet
>>> > <jppoet@gmail.com <mailto:jppoet@gmail.com>> wrote:
>>> > >>
>>> > >>> I just upgraded from 39b850f1a9 to 06da3119d5 and
>>> > discovered that frame
>>> > >>> counting is now broken for ffmpeg/nvenc encoded HVEC. The
>>> > OSD indicates
>>> > >>> that the shows are twice as long as they really are.
>>> > >>>
>>> > >>> This weekend I will do a bisec to figure out which commit
>>> > did the damage,
>>> > >>> unless someone else already knows?
>>> > >>>
>>> > >> Sorry. Make that 26b2e76ae to 06da3119d5.
>>> > > It's probably the very, recent, ffmpeg merge.
>>> > >
>>> > > While you're in there, though, would you mind looking into
>>> the
>>> > > long-standing issue with mythcommflag --rebuild not working
>>> > on HEVC
>>> > > encoded files, or at least those encoded by HandBarke? :)
>>> >
>>> > A note on bisecting the recent FFmpeg merge:
>>> >
>>> a1868defe9c48c5ca53e1c5d26010a19ebd7db13..753a94ccb7a39ef66c6f8591e5784bf08a1b002e
>>> >
>>> > wont compile (inclusive..exclusive) fully because of how I
>>> split
>>> > the
>>> > commits.
>>> >
>>> > My harmonization of libavcodec/mpegts-mythtv.c is also in the
>>> > range you
>>> > gave. While each commit compiles, I didn't test functionality
>>> > of each
>>> > commit. But, even if the container is an MPEG-TS, I would also
>>> > suspect
>>> > the new version of FFmpeg.
>>> >
>>> > Could be related to (HEVC):
>>> > Playback of DVB recordings shows displayed time doubled · Issue
>>> > #548 ·
>>> > MythTV/mythtv · GitHub
>>> > https://github.com/MythTV/mythtv/issues/548
>>> > <https://github.com/MythTV/mythtv/issues/548>
>>> > ?
>>> >
>>> > Regards,
>>> >
>>> > Scott
>>> >
>>> >
>>> > Thank you Scott.
>>> >
>>> > What is bizaar is that I went back to 39b850f1a9 and it was still
>>> > doubling. I could have sworn that was the commit I was running
>>> > before! I ended up jumping back and back and back until I randomly
>>> > found 31ee7f9e64 to work correctly. So, now I have to say the
>>> > problem occured somewhere between 31ee7f9e64 and 3e802f9075. I will
>>> > try and narrow it down tomorrow.
>>> >
>>> >
>>> > Okay, so I was running 39b850f1a9 on my production machine and
>>> > 26b2e76ae on my development machine. I had not noticed the issue on my
>>> > dev machine.
>>> >
>>> > The problem does seem to be between 31ee7f9e64 and 3e802f9075. Looking
>>> > at the commits in that range, 40fb3cd09d and db93047399 seem like
>>> > possibilities. My production machine is now recording stuff for the
>>> > evening so I will test more tomorrow.
>>> >
>>> > John
>>>
>>> Issue #548 was reported as being years-old for some HEVC recordings. I
>>> had similar issues with just one of six DVB-T (mpeg2ts) multiplexes, now
>>> fixed by PR#610.
>>>
>>> mythcommflag --rebuild gave good frame counts for me, but gigem says it
>>> doesn't work with handbrake's HEVC encoding.
>>>
>>> It looks to me as if ffmpeg doesn't understand 'with field pictures'
>>> encoding.
>>>
>>
>> Doing a git bisect on my 10 year old production mythbackend machine is a
>> bit painful, but the result is that 7b2ac1eeb5 is the culprit. I see that
>> a6e1128e0f2 fixes a problem caused by 7b2ac1eeb5 but not this one. I will
>> work on narrowing down the problem.
>>
>
> HEVCParser::parseSPS is seriously broken with 7b2ac1eeb5. It does not
> even get the sps_id correct, let alone width, height or timescale. I have
> spent the last several hours trying to figure out exactly where the parsing
> goes wrong but have not tracked it down yet.
>

I really think that 7b2ac1eeb5 should be reverted. At least until a new
version can be written which doesn't break so much logic. I tried just
doing that against master, but myth's ffmpeg api has changed enough that it
is not straight forward...

John
Re: HVEC frame counting broken [ In reply to ]
On 9/25/22 00:10, John P Poet wrote:
> On Sat, Sep 24, 2022 at 7:01 PM John P Poet <jppoet@gmail.com> wrote:
>
> On Sat, Sep 24, 2022 at 3:35 PM John P Poet <jppoet@gmail.com> wrote:
>
> On Sat, Sep 24, 2022 at 3:38 AM John Pilkington
> <johnpilk222@gmail.com> wrote:
>
> On 24/09/2022 02:18, John P Poet wrote:
> > On Fri, Sep 23, 2022 at 7:02 PM John P Poet
> <jppoet@gmail.com
> > <mailto:jppoet@gmail.com>> wrote:
> >
> >     On Fri, Sep 23, 2022 at 6:31 PM Scott Theisen
> >     <scott.the.elm@gmail.com
> <mailto:scott.the.elm@gmail.com>> wrote:
> >
> >         On 9/23/22 18:59, David Engel wrote:
> >          > On Fri, Sep 23, 2022 at 04:38:19PM -0600,
> John P Poet wrote:
> >          >> On Fri, Sep 23, 2022 at 4:32 PM John P Poet
> >         <jppoet@gmail.com <mailto:jppoet@gmail.com>> wrote:
> >          >>
> >          >>> I just upgraded from 39b850f1a9 to
> 06da3119d5 and
> >         discovered that frame
> >          >>> counting is now broken for ffmpeg/nvenc
> encoded HVEC. The
> >         OSD indicates
> >          >>> that the shows are twice as long as they
> really are.
> >          >>>
> >          >>> This weekend I will do a bisec to figure
> out which commit
> >         did the damage,
> >          >>> unless someone else already knows?
> >          >>>
> >          >> Sorry. Make that 26b2e76ae to 06da3119d5.
> >          > It's probably the very, recent, ffmpeg merge.
> >          >
> >          > While you're in there, though, would you mind
> looking into the
> >          > long-standing issue with mythcommflag
> --rebuild not working
> >         on HEVC
> >          > encoded files, or at least those encoded by
> HandBarke? :)
> >
> >         A note on bisecting the recent FFmpeg merge:
> >
>  a1868defe9c48c5ca53e1c5d26010a19ebd7db13..753a94ccb7a39ef66c6f8591e5784bf08a1b002e
> >
> >         wont compile (inclusive..exclusive) fully
> because of how I split
> >         the
> >         commits.
> >
> >         My harmonization of libavcodec/mpegts-mythtv.c
> is also in the
> >         range you
> >         gave.  While each commit compiles, I didn't test
> functionality
> >         of each
> >         commit.  But, even if the container is an
> MPEG-TS, I would also
> >         suspect
> >         the new version of FFmpeg.
> >
> >         Could be related to (HEVC):
> >         Playback of DVB recordings shows displayed time
> doubled · Issue
> >         #548 ·
> >         MythTV/mythtv · GitHub
> > https://github.com/MythTV/mythtv/issues/548
> >         <https://github.com/MythTV/mythtv/issues/548>
> >         ?
> >
> >         Regards,
> >
> >         Scott
> >
> >
> >     Thank you Scott.
> >
> >     What is bizaar is that I went back to 39b850f1a9 and
> it was still
> >     doubling. I could have sworn that was the commit I
> was running
> >     before! I ended up jumping back and back and back
> until I randomly
> >     found 31ee7f9e64 to work correctly. So, now I have
> to say the
> >     problem occured somewhere between 31ee7f9e64 and
> 3e802f9075. I will
> >     try and narrow it down tomorrow.
> >
> >
> > Okay, so I was running  39b850f1a9 on my production
> machine and
> > 26b2e76ae on my development machine. I had not noticed
> the issue on my
> > dev machine.
> >
> > The problem does seem to be between 31ee7f9e64 and
> 3e802f9075. Looking
> > at the commits in that range, 40fb3cd09d and db93047399
> seem like
> > possibilities. My production machine is now recording
> stuff for the
> > evening so I will test more tomorrow.
> >
> > John
>
> Issue #548 was reported as being years-old for some HEVC
> recordings.  I
> had similar issues with just one of six DVB-T (mpeg2ts)
> multiplexes, now
> fixed by PR#610.
>
> mythcommflag --rebuild gave good frame counts for me, but
> gigem says it
> doesn't work with handbrake's HEVC encoding.
>
> It looks to me as if ffmpeg doesn't understand 'with field
> pictures'
> encoding.
>
>
> Doing a git bisect on my 10 year old production mythbackend
> machine is a bit painful, but the result is that 7b2ac1eeb5 is
> the culprit. I see that a6e1128e0f2 fixes a problem caused by
> 7b2ac1eeb5 but not this one. I will work on narrowing down the
> problem.
>
>
>  HEVCParser::parseSPS is seriously broken with 7b2ac1eeb5. It does
> not even get the sps_id correct, let alone width, height or
> timescale. I have spent the last several hours trying to figure
> out exactly where the parsing goes wrong but have not tracked it
> down yet.
>
>
> I really think that 7b2ac1eeb5 should be reverted. At least until a
> new version can be written which doesn't break so much logic. I tried
> just doing that against master, but myth's ffmpeg api has changed
> enough that it is not straight forward...
>
> John
>

The API hasn't changed; you just need to re-add the exports.  In
addition to reverting a6e1128e0f2 and 7b2ac1eeb5, you also need to first
partially revert
https://github.com/MythTV/mythtv/commit/4e5b66eaab3936c90f4de1d2e8318f024c771f0b
like this:

```
diff --git a/mythtv/external/FFmpeg/libavcodec/libavcodec.v
b/mythtv/external/FFmpeg/libavcodec/libavcodec.v
index d863e056a5..3f01fd3fd5 100644
--- a/mythtv/external/FFmpeg/libavcodec/libavcodec.v
+++ b/mythtv/external/FFmpeg/libavcodec/libavcodec.v
@@ -4,6 +4,9 @@ LIBAVCODEC_MAJOR {
         avcodec_*;
         avpriv_*;
         avsubtitle_free;
+        ff_ue_golomb_vlc_code;
+        ff_golomb_vlc_len;
+        ff_se_golomb_vlc_code;
     local:
         *;
 };
```

However, I would also like to hide the includes of get_bits.h and
golomb.h in the parsers' .cpp files.

Could you share your sample and instructions to reproduce so I can test
it?  I would prefer to fix it instead of reverting it since these are
internal FFmpeg headers.

Thanks

Scott
Re: HVEC frame counting broken [ In reply to ]
On Sun, Sep 25, 2022 at 8:07 AM Scott Theisen <scott.the.elm@gmail.com>
wrote:

> On 9/25/22 00:10, John P Poet wrote:
>
> On Sat, Sep 24, 2022 at 7:01 PM John P Poet <jppoet@gmail.com> wrote:
>
>> On Sat, Sep 24, 2022 at 3:35 PM John P Poet <jppoet@gmail.com> wrote:
>>
>>> On Sat, Sep 24, 2022 at 3:38 AM John Pilkington <johnpilk222@gmail.com>
>>> wrote:
>>>
>>>> On 24/09/2022 02:18, John P Poet wrote:
>>>> > On Fri, Sep 23, 2022 at 7:02 PM John P Poet <jppoet@gmail.com
>>>> > <mailto:jppoet@gmail.com>> wrote:
>>>> >
>>>> > On Fri, Sep 23, 2022 at 6:31 PM Scott Theisen
>>>> > <scott.the.elm@gmail.com <mailto:scott.the.elm@gmail.com>> wrote:
>>>> >
>>>> > On 9/23/22 18:59, David Engel wrote:
>>>> > > On Fri, Sep 23, 2022 at 04:38:19PM -0600, John P Poet
>>>> wrote:
>>>> > >> On Fri, Sep 23, 2022 at 4:32 PM John P Poet
>>>> > <jppoet@gmail.com <mailto:jppoet@gmail.com>> wrote:
>>>> > >>
>>>> > >>> I just upgraded from 39b850f1a9 to 06da3119d5 and
>>>> > discovered that frame
>>>> > >>> counting is now broken for ffmpeg/nvenc encoded HVEC. The
>>>> > OSD indicates
>>>> > >>> that the shows are twice as long as they really are.
>>>> > >>>
>>>> > >>> This weekend I will do a bisec to figure out which commit
>>>> > did the damage,
>>>> > >>> unless someone else already knows?
>>>> > >>>
>>>> > >> Sorry. Make that 26b2e76ae to 06da3119d5.
>>>> > > It's probably the very, recent, ffmpeg merge.
>>>> > >
>>>> > > While you're in there, though, would you mind looking into
>>>> the
>>>> > > long-standing issue with mythcommflag --rebuild not working
>>>> > on HEVC
>>>> > > encoded files, or at least those encoded by HandBarke? :)
>>>> >
>>>> > A note on bisecting the recent FFmpeg merge:
>>>> >
>>>> a1868defe9c48c5ca53e1c5d26010a19ebd7db13..753a94ccb7a39ef66c6f8591e5784bf08a1b002e
>>>> >
>>>> > wont compile (inclusive..exclusive) fully because of how I
>>>> split
>>>> > the
>>>> > commits.
>>>> >
>>>> > My harmonization of libavcodec/mpegts-mythtv.c is also in the
>>>> > range you
>>>> > gave. While each commit compiles, I didn't test functionality
>>>> > of each
>>>> > commit. But, even if the container is an MPEG-TS, I would
>>>> also
>>>> > suspect
>>>> > the new version of FFmpeg.
>>>> >
>>>> > Could be related to (HEVC):
>>>> > Playback of DVB recordings shows displayed time doubled ·
>>>> Issue
>>>> > #548 ·
>>>> > MythTV/mythtv · GitHub
>>>> > https://github.com/MythTV/mythtv/issues/548
>>>> > <https://github.com/MythTV/mythtv/issues/548>
>>>> > ?
>>>> >
>>>> > Regards,
>>>> >
>>>> > Scott
>>>> >
>>>> >
>>>> > Thank you Scott.
>>>> >
>>>> > What is bizaar is that I went back to 39b850f1a9 and it was still
>>>> > doubling. I could have sworn that was the commit I was running
>>>> > before! I ended up jumping back and back and back until I randomly
>>>> > found 31ee7f9e64 to work correctly. So, now I have to say the
>>>> > problem occured somewhere between 31ee7f9e64 and 3e802f9075. I
>>>> will
>>>> > try and narrow it down tomorrow.
>>>> >
>>>> >
>>>> > Okay, so I was running 39b850f1a9 on my production machine and
>>>> > 26b2e76ae on my development machine. I had not noticed the issue on
>>>> my
>>>> > dev machine.
>>>> >
>>>> > The problem does seem to be between 31ee7f9e64 and 3e802f9075.
>>>> Looking
>>>> > at the commits in that range, 40fb3cd09d and db93047399 seem like
>>>> > possibilities. My production machine is now recording stuff for the
>>>> > evening so I will test more tomorrow.
>>>> >
>>>> > John
>>>>
>>>> Issue #548 was reported as being years-old for some HEVC recordings. I
>>>> had similar issues with just one of six DVB-T (mpeg2ts) multiplexes,
>>>> now
>>>> fixed by PR#610.
>>>>
>>>> mythcommflag --rebuild gave good frame counts for me, but gigem says it
>>>> doesn't work with handbrake's HEVC encoding.
>>>>
>>>> It looks to me as if ffmpeg doesn't understand 'with field pictures'
>>>> encoding.
>>>>
>>>
>>> Doing a git bisect on my 10 year old production mythbackend machine is a
>>> bit painful, but the result is that 7b2ac1eeb5 is the culprit. I see that
>>> a6e1128e0f2 fixes a problem caused by 7b2ac1eeb5 but not this one. I will
>>> work on narrowing down the problem.
>>>
>>
>> HEVCParser::parseSPS is seriously broken with 7b2ac1eeb5. It does not
>> even get the sps_id correct, let alone width, height or timescale. I have
>> spent the last several hours trying to figure out exactly where the parsing
>> goes wrong but have not tracked it down yet.
>>
>
> I really think that 7b2ac1eeb5 should be reverted. At least until a new
> version can be written which doesn't break so much logic. I tried just
> doing that against master, but myth's ffmpeg api has changed enough that it
> is not straight forward...
>
> John
>
>
> The API hasn't changed; you just need to re-add the exports. In addition
> to reverting a6e1128e0f2 and 7b2ac1eeb5, you also need to first partially
> revert
> https://github.com/MythTV/mythtv/commit/4e5b66eaab3936c90f4de1d2e8318f024c771f0b
> like this:
>
> ```
> diff --git a/mythtv/external/FFmpeg/libavcodec/libavcodec.v
> b/mythtv/external/FFmpeg/libavcodec/libavcodec.v
> index d863e056a5..3f01fd3fd5 100644
> --- a/mythtv/external/FFmpeg/libavcodec/libavcodec.v
> +++ b/mythtv/external/FFmpeg/libavcodec/libavcodec.v
> @@ -4,6 +4,9 @@ LIBAVCODEC_MAJOR {
> avcodec_*;
> avpriv_*;
> avsubtitle_free;
> + ff_ue_golomb_vlc_code;
> + ff_golomb_vlc_len;
> + ff_se_golomb_vlc_code;
> local:
> *;
> };
> ```
>
> However, I would also like to hide the includes of get_bits.h and golomb.h
> in the parsers' .cpp files.
>
> Could you share your sample and instructions to reproduce so I can test
> it? I would prefer to fix it instead of reverting it since these are
> internal FFmpeg headers.
>
> Thanks
>
> 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


Thank you Scott. I just uploaded a HEVC sample to dropbox. It should be
shared with you.

Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
sps_id: 0
width, height: 1920x1088
unitsInTick / timeScale: 166817 / 10000000

With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id, width and height are
garbage and the unitsinTick / timeScale are never decoded --
vps_extension_flag is zero.

My best guess is that there is an alignment issue and the BitReader that is
being passed into HEVCParser::parseSPS is not pointing at the correct
position.

John
Re: HVEC frame counting broken [ In reply to ]
On 9/25/22 11:43, John P Poet wrote:
>
>
> Thank you Scott. I just uploaded a HEVC sample to dropbox. It should
> be shared with you.

I have the sample.

>
> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
> sps_id: 0
> width, height: 1920x1088
> unitsInTick / timeScale: 166817 / 10000000
>
> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id, width and height are
> garbage and the unitsinTick / timeScale are never decoded --
> vps_extension_flag is zero.
>
> My best guess is that there is an alignment issue and the BitReader
> that is being passed into HEVCParser::parseSPS is not pointing at the
> correct position.
>

OK, but how are you getting the code to execute on the sample?
mythcommflag --rebuild something?  Adding to Videos and scanning for
changes?

Thanks,

Scott
Re: HVEC frame counting broken [ In reply to ]
On Sun, Sep 25, 2022 at 10:33 AM Scott Theisen <scott.the.elm@gmail.com>
wrote:

> On 9/25/22 11:43, John P Poet wrote:
>
>
>
> Thank you Scott. I just uploaded a HEVC sample to dropbox. It should be
> shared with you.
>
>
> I have the sample.
>
>
> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
> sps_id: 0
> width, height: 1920x1088
> unitsInTick / timeScale: 166817 / 10000000
>
> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id, width and height are
> garbage and the unitsinTick / timeScale are never decoded --
> vps_extension_flag is zero.
>
> My best guess is that there is an alignment issue and the BitReader that
> is being passed into HEVCParser::parseSPS is not pointing at the correct
> position.
>
>
> OK, but how are you getting the code to execute on the sample?
> mythcommflag --rebuild something? Adding to Videos and scanning for
> changes?
>
> Thanks,
>
> Scott
>

I am using an ExternalRecorder (https://github.com/jpoet/Magewell2TS).
Using the mythfilerecorder ExternalRecorder that is packaged with Myth
should provide the same result. I am pretty sure that `mythcommflag
--rebuild` results in a different code path and I have not tried it.

If you have trouble setting up mythfilerecorder I will do that this
afternoon and then send you instructions.

John
Re: HVEC frame counting broken [ In reply to ]
On Sun, Sep 25, 2022 at 10:40 AM John P Poet <jppoet@gmail.com> wrote:

> On Sun, Sep 25, 2022 at 10:33 AM Scott Theisen <scott.the.elm@gmail.com>
> wrote:
>
>> On 9/25/22 11:43, John P Poet wrote:
>>
>>
>>
>> Thank you Scott. I just uploaded a HEVC sample to dropbox. It should be
>> shared with you.
>>
>>
>> I have the sample.
>>
>>
>> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
>> sps_id: 0
>> width, height: 1920x1088
>> unitsInTick / timeScale: 166817 / 10000000
>>
>> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id, width and height are
>> garbage and the unitsinTick / timeScale are never decoded --
>> vps_extension_flag is zero.
>>
>> My best guess is that there is an alignment issue and the BitReader that
>> is being passed into HEVCParser::parseSPS is not pointing at the correct
>> position.
>>
>>
>> OK, but how are you getting the code to execute on the sample?
>> mythcommflag --rebuild something? Adding to Videos and scanning for
>> changes?
>>
>> Thanks,
>>
>> Scott
>>
>
> I am using an ExternalRecorder (https://github.com/jpoet/Magewell2TS).
> Using the mythfilerecorder ExternalRecorder that is packaged with Myth
> should provide the same result. I am pretty sure that `mythcommflag
> --rebuild` results in a different code path and I have not tried it.
>
> If you have trouble setting up mythfilerecorder I will do that this
> afternoon and then send you instructions.
>

Actually, I won't. I keep forgetting that I don't currently have access to
my development machine and my production machine will be recording football
today. So, that would have to wait until tomorrow sometime.

John
Re: HVEC frame counting broken [ In reply to ]
See also issue https://github.com/MythTV/mythtv/issues/620 and commit
a6e1128e0f2e0ebf8040479e3b6393d940b14a7c about a fix in the HEVCParser
related to the BitReader.

Klaas.
Re: HVEC frame counting broken [ In reply to ]
On 9/25/22 12:42, John P Poet wrote:
> On Sun, Sep 25, 2022 at 10:40 AM John P Poet <jppoet@gmail.com> wrote:
>
> On Sun, Sep 25, 2022 at 10:33 AM Scott Theisen
> <scott.the.elm@gmail.com> wrote:
>
> On 9/25/22 11:43, John P Poet wrote:
>>
>>
>> Thank you Scott. I just uploaded a HEVC sample to dropbox. It
>> should be shared with you.
>
> I have the sample.
>
>>
>> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
>> sps_id: 0
>> width, height: 1920x1088
>> unitsInTick / timeScale: 166817 / 10000000
>>
>> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id, width and
>> height are garbage and the unitsinTick / timeScale are never
>> decoded -- vps_extension_flag is zero.
>>
>> My best guess is that there is an alignment issue and the
>> BitReader that is being passed into HEVCParser::parseSPS is
>> not pointing at the correct position.
>>
>
> OK, but how are you getting the code to execute on the
> sample?  mythcommflag --rebuild something? Adding to Videos
> and scanning for changes?
>
> Thanks,
>
> Scott
>
>
> I am using an ExternalRecorder
> (https://github.com/jpoet/Magewell2TS). Using the mythfilerecorder
> ExternalRecorder that is packaged with Myth should provide the
> same result. I am pretty sure that `mythcommflag --rebuild`
> results in a different code path and I have not tried it.
>
> If you have trouble setting up mythfilerecorder I will do that
> this afternoon and then send you instructions.
>
>
> Actually, I won't. I keep forgetting that I don't currently have
> access to my development machine and my production machine will be
> recording football today. So, that would have to wait until tomorrow
> sometime.
>
> John

I couldn't figure out how to get mythfilerecorder to work, so
instructions from you, or anyone, would be appreciated.

Scott
Re: HVEC frame counting broken [ In reply to ]
On Sun, Sep 25, 2022 at 3:16 PM Scott Theisen <scott.the.elm@gmail.com>
wrote:

>
>
> On 9/25/22 12:42, John P Poet wrote:
>
> On Sun, Sep 25, 2022 at 10:40 AM John P Poet <jppoet@gmail.com> wrote:
>
>> On Sun, Sep 25, 2022 at 10:33 AM Scott Theisen <scott.the.elm@gmail.com>
>> wrote:
>>
>>> On 9/25/22 11:43, John P Poet wrote:
>>>
>>>
>>>
>>> Thank you Scott. I just uploaded a HEVC sample to dropbox. It should be
>>> shared with you.
>>>
>>>
>>> I have the sample.
>>>
>>>
>>> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
>>> sps_id: 0
>>> width, height: 1920x1088
>>> unitsInTick / timeScale: 166817 / 10000000
>>>
>>> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id, width and height are
>>> garbage and the unitsinTick / timeScale are never decoded --
>>> vps_extension_flag is zero.
>>>
>>> My best guess is that there is an alignment issue and the BitReader that
>>> is being passed into HEVCParser::parseSPS is not pointing at the correct
>>> position.
>>>
>>>
>>> OK, but how are you getting the code to execute on the sample?
>>> mythcommflag --rebuild something? Adding to Videos and scanning for
>>> changes?
>>>
>>> Thanks,
>>>
>>> Scott
>>>
>>
>> I am using an ExternalRecorder (https://github.com/jpoet/Magewell2TS).
>> Using the mythfilerecorder ExternalRecorder that is packaged with Myth
>> should provide the same result. I am pretty sure that `mythcommflag
>> --rebuild` results in a different code path and I have not tried it.
>>
>> If you have trouble setting up mythfilerecorder I will do that this
>> afternoon and then send you instructions.
>>
>
> Actually, I won't. I keep forgetting that I don't currently have access to
> my development machine and my production machine will be recording football
> today. So, that would have to wait until tomorrow sometime.
>
> John
>
>
> I couldn't figure out how to get mythfilerecorder to work, so instructions
> from you, or anyone, would be appreciated.
>
> Scott
>

I cannot test this until tomorrow, but this should work...

Put the attached config files in /home/mythtv/etc/ . Modify externfile.conf
so it can find the sample hevc file.

Create a new "capture card" of type "External (blackbox) Recorder". For the
command path use "/usr/local/bin/mythexternrecorder --conf
/home/mythtv/etc/externfile.conf". Modify that if your mythexternrecorder
is not in /usr/local/bin.

You may want/need to create a new source for this capture card.

You can do a "channel scan" for the new input and it will pick up the test
channel defined in channels.conf. You can then create a manual record for
that channel and it will effectively "record" the hevc sample file.

John
Re: HVEC frame counting broken [ In reply to ]
On 9/25/22 18:48, John P Poet wrote:
> On Sun, Sep 25, 2022 at 3:16 PM Scott Theisen
> <scott.the.elm@gmail.com> wrote:
>
>
>
> On 9/25/22 12:42, John P Poet wrote:
>> On Sun, Sep 25, 2022 at 10:40 AM John P Poet <jppoet@gmail.com>
>> wrote:
>>
>> On Sun, Sep 25, 2022 at 10:33 AM Scott Theisen
>> <scott.the.elm@gmail.com> wrote:
>>
>> On 9/25/22 11:43, John P Poet wrote:
>>>
>>>
>>> Thank you Scott. I just uploaded a HEVC sample to
>>> dropbox. It should be shared with you.
>>
>> I have the sample.
>>
>>>
>>> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
>>> sps_id: 0
>>> width, height: 1920x1088
>>> unitsInTick / timeScale: 166817 / 10000000
>>>
>>> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id, width
>>> and height are garbage and the unitsinTick / timeScale
>>> are never decoded -- vps_extension_flag is zero.
>>>
>>> My best guess is that there is an alignment issue and
>>> the BitReader that is being passed into
>>> HEVCParser::parseSPS is not pointing at the correct
>>> position.
>>>
>>
>> OK, but how are you getting the code to execute on the
>> sample?  mythcommflag --rebuild something?  Adding to
>> Videos and scanning for changes?
>>
>> Thanks,
>>
>> Scott
>>
>>
>> I am using an ExternalRecorder
>> (https://github.com/jpoet/Magewell2TS). Using the
>> mythfilerecorder ExternalRecorder that is packaged with Myth
>> should provide the same result. I am pretty sure that
>> `mythcommflag --rebuild` results in a different code path and
>> I have not tried it.
>>
>> If you have trouble setting up mythfilerecorder I will do
>> that this afternoon and then send you instructions.
>>
>>
>> Actually, I won't. I keep forgetting that I don't currently have
>> access to my development machine and my production machine will
>> be recording football today. So, that would have to wait until
>> tomorrow sometime.
>>
>> John
>
> I couldn't figure out how to get mythfilerecorder to work, so
> instructions from you, or anyone, would be appreciated.
>
> Scott
>
>
> I cannot test this until tomorrow, but this should work...
>
> Put the attached config files in /home/mythtv/etc/ . Modify
> externfile.conf so it can find the sample hevc file.
>
> Create a new "capture card" of type "External (blackbox) Recorder".
> For the command path use "/usr/local/bin/mythexternrecorder --conf
> /home/mythtv/etc/externfile.conf". Modify that if your
> mythexternrecorder is not in /usr/local/bin.
>
> You may want/need to create a new source for this capture card.
>
> You can do a "channel scan" for the new input and it will pick up the
> test channel defined in channels.conf. You can then create a manual
> record for that channel and it will effectively "record" the hevc
> sample file.
>
>

Thanks, that worked, adjusting the paths to the real values. However, it
loops the input file and creates recordings far longer than the
specified manual recording duration.

I can confirm that parsing is broken. :(

Let me know if you want me to open a pull request reverting the change
to BitReader, while I investigate.

Thanks,

Scott

PS--Unrelated, but apparently "HEVC" is not a valid registration
descriptor according to MythTV:
```
2022-09-25 20:57:29.612931 D [17701/17792] ExternSH
mpegstreamdata.cpp:463 (CreatePMTSingleProgram) -
MPEGStream[8](0x7f2f840261b0): Program Map Section
  PSIP tableID(0x2) length(35) extension(0x1)
       version(0) current(1) section(0) last_section(0)
       pnum(1) pid(0x1000) pcrpid(0x100)
  Stream #0 pid(0x100) type(0x24 video-h265)
    Registration Descriptor: 'HEVC' Unknown, see
http://www.smpte-ra.org/mpegreg/mpegreg.html
  Stream #1 pid(0x101) type(0x81 audio-ac3)
    Registration Descriptor: 'AC-3' ATSC audio stream A/52
```
Re: HVEC frame counting broken [ In reply to ]
On Sun, Sep 25, 2022 at 8:17 PM Scott Theisen <scott.the.elm@gmail.com>
wrote:

> On 9/25/22 18:48, John P Poet wrote:
>
> On Sun, Sep 25, 2022 at 3:16 PM Scott Theisen <scott.the.elm@gmail.com>
> wrote:
>
>>
>>
>> On 9/25/22 12:42, John P Poet wrote:
>>
>> On Sun, Sep 25, 2022 at 10:40 AM John P Poet <jppoet@gmail.com> wrote:
>>
>>> On Sun, Sep 25, 2022 at 10:33 AM Scott Theisen <scott.the.elm@gmail.com>
>>> wrote:
>>>
>>>> On 9/25/22 11:43, John P Poet wrote:
>>>>
>>>>
>>>>
>>>> Thank you Scott. I just uploaded a HEVC sample to dropbox. It should be
>>>> shared with you.
>>>>
>>>>
>>>> I have the sample.
>>>>
>>>>
>>>> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
>>>> sps_id: 0
>>>> width, height: 1920x1088
>>>> unitsInTick / timeScale: 166817 / 10000000
>>>>
>>>> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id, width and height are
>>>> garbage and the unitsinTick / timeScale are never decoded --
>>>> vps_extension_flag is zero.
>>>>
>>>> My best guess is that there is an alignment issue and the BitReader
>>>> that is being passed into HEVCParser::parseSPS is not pointing at the
>>>> correct position.
>>>>
>>>>
>>>> OK, but how are you getting the code to execute on the sample?
>>>> mythcommflag --rebuild something? Adding to Videos and scanning for
>>>> changes?
>>>>
>>>> Thanks,
>>>>
>>>> Scott
>>>>
>>>
>>> I am using an ExternalRecorder (https://github.com/jpoet/Magewell2TS).
>>> Using the mythfilerecorder ExternalRecorder that is packaged with Myth
>>> should provide the same result. I am pretty sure that `mythcommflag
>>> --rebuild` results in a different code path and I have not tried it.
>>>
>>> If you have trouble setting up mythfilerecorder I will do that this
>>> afternoon and then send you instructions.
>>>
>>
>> Actually, I won't. I keep forgetting that I don't currently have access
>> to my development machine and my production machine will be recording
>> football today. So, that would have to wait until tomorrow sometime.
>>
>> John
>>
>>
>> I couldn't figure out how to get mythfilerecorder to work, so
>> instructions from you, or anyone, would be appreciated.
>>
>> Scott
>>
>
> I cannot test this until tomorrow, but this should work...
>
> Put the attached config files in /home/mythtv/etc/ . Modify
> externfile.conf so it can find the sample hevc file.
>
> Create a new "capture card" of type "External (blackbox) Recorder". For
> the command path use "/usr/local/bin/mythexternrecorder --conf
> /home/mythtv/etc/externfile.conf". Modify that if your mythexternrecorder
> is not in /usr/local/bin.
>
> You may want/need to create a new source for this capture card.
>
> You can do a "channel scan" for the new input and it will pick up the test
> channel defined in channels.conf. You can then create a manual record for
> that channel and it will effectively "record" the hevc sample file.
>
>
>
> Thanks, that worked, adjusting the paths to the real values. However, it
> loops the input file and creates recordings far longer than the specified
> manual recording duration.
>
> I can confirm that parsing is broken. :(
>
> Let me know if you want me to open a pull request reverting the change to
> BitReader, while I investigate.
>
> Thanks,
>
> Scott
>
> PS--Unrelated, but apparently "HEVC" is not a valid registration
> descriptor according to MythTV:
> ```
> 2022-09-25 20:57:29.612931 D [17701/17792] ExternSH mpegstreamdata.cpp:463
> (CreatePMTSingleProgram) - MPEGStream[8](0x7f2f840261b0): Program Map
> Section
> PSIP tableID(0x2) length(35) extension(0x1)
> version(0) current(1) section(0) last_section(0)
> pnum(1) pid(0x1000) pcrpid(0x100)
> Stream #0 pid(0x100) type(0x24 video-h265)
> Registration Descriptor: 'HEVC' Unknown, see
> http://www.smpte-ra.org/mpegreg/mpegreg.html
> Stream #1 pid(0x101) type(0x81 audio-ac3)
> Registration Descriptor: 'AC-3' ATSC audio stream A/52
> ```
>

Interesting about the HEVC descriptor. I will look into that. I will also
look into the looping you mention. I will probably wait until I have direct
access to my "dev" machine first, though, since doing that kind of
debugging is inconvenient on a live system.

If you can figure out the problem within the next few of days, then you can
leave it. If you think it will take longer, then yes I would like that
commit to be reversed.

Thank you,

John
Re: HVEC frame counting broken [ In reply to ]
On 9/25/22 21:38, John P Poet wrote:
> On Sun, Sep 25, 2022 at 8:17 PM Scott Theisen
> <scott.the.elm@gmail.com> wrote:
>
> On 9/25/22 18:48, John P Poet wrote:
>> On Sun, Sep 25, 2022 at 3:16 PM Scott Theisen
>> <scott.the.elm@gmail.com> wrote:
>>
>>
>>
>> On 9/25/22 12:42, John P Poet wrote:
>>> On Sun, Sep 25, 2022 at 10:40 AM John P Poet
>>> <jppoet@gmail.com> wrote:
>>>
>>> On Sun, Sep 25, 2022 at 10:33 AM Scott Theisen
>>> <scott.the.elm@gmail.com> wrote:
>>>
>>> On 9/25/22 11:43, John P Poet wrote:
>>>>
>>>>
>>>> Thank you Scott. I just uploaded a HEVC sample to
>>>> dropbox. It should be shared with you.
>>>
>>> I have the sample.
>>>
>>>>
>>>> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
>>>> sps_id: 0
>>>> width, height: 1920x1088
>>>> unitsInTick / timeScale: 166817 / 10000000
>>>>
>>>> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id,
>>>> width and height are garbage and the unitsinTick /
>>>> timeScale are never decoded -- vps_extension_flag
>>>> is zero.
>>>>
>>>> My best guess is that there is an alignment issue
>>>> and the BitReader that is being passed into
>>>> HEVCParser::parseSPS is not pointing at the correct
>>>> position.
>>>>
>>>
>>> OK, but how are you getting the code to execute on
>>> the sample? mythcommflag --rebuild something? 
>>> Adding to Videos and scanning for changes?
>>>
>>> Thanks,
>>>
>>> Scott
>>>
>>>
>>> I am using an ExternalRecorder
>>> (https://github.com/jpoet/Magewell2TS). Using the
>>> mythfilerecorder ExternalRecorder that is packaged with
>>> Myth should provide the same result. I am pretty sure
>>> that `mythcommflag --rebuild` results in a different
>>> code path and I have not tried it.
>>>
>>> If you have trouble setting up mythfilerecorder I will
>>> do that this afternoon and then send you instructions.
>>>
>>>
>>> Actually, I won't. I keep forgetting that I don't currently
>>> have access to my development machine and my production
>>> machine will be recording football today. So, that would
>>> have to wait until tomorrow sometime.
>>>
>>> John
>>
>> I couldn't figure out how to get mythfilerecorder to work, so
>> instructions from you, or anyone, would be appreciated.
>>
>> Scott
>>
>>
>> I cannot test this until tomorrow, but this should work...
>>
>> Put the attached config files in /home/mythtv/etc/ . Modify
>> externfile.conf so it can find the sample hevc file.
>>
>> Create a new "capture card" of type "External (blackbox)
>> Recorder". For the command path use
>> "/usr/local/bin/mythexternrecorder --conf
>> /home/mythtv/etc/externfile.conf". Modify that if your
>> mythexternrecorder is not in /usr/local/bin.
>>
>> You may want/need to create a new source for this capture card.
>>
>> You can do a "channel scan" for the new input and it will pick up
>> the test channel defined in channels.conf. You can then create a
>> manual record for that channel and it will effectively "record"
>> the hevc sample file.
>>
>>
>
> Thanks, that worked, adjusting the paths to the real values. 
> However, it loops the input file and creates recordings far longer
> than the specified manual recording duration.
>
> I can confirm that parsing is broken. :(
>
> Let me know if you want me to open a pull request reverting the
> change to BitReader, while I investigate.
>
> Thanks,
>
> Scott
>
> PS--Unrelated, but apparently "HEVC" is not a valid registration
> descriptor according to MythTV:
> ```
> 2022-09-25 20:57:29.612931 D [17701/17792] ExternSH
> mpegstreamdata.cpp:463 (CreatePMTSingleProgram) -
> MPEGStream[8](0x7f2f840261b0): Program Map Section
>   PSIP tableID(0x2) length(35) extension(0x1)
>        version(0) current(1) section(0) last_section(0)
>        pnum(1) pid(0x1000) pcrpid(0x100)
>   Stream #0 pid(0x100) type(0x24 video-h265)
>     Registration Descriptor: 'HEVC' Unknown, see
> http://www.smpte-ra.org/mpegreg/mpegreg.html
>   Stream #1 pid(0x101) type(0x81 audio-ac3)
>     Registration Descriptor: 'AC-3' ATSC audio stream A/52
> ```
>
>
> Interesting about the HEVC descriptor. I will look into that. I will
> also look into the looping you mention. I will probably wait until I
> have direct access to my "dev" machine first, though, since doing that
> kind of debugging is inconvenient on a live system.
>
> If you can figure out the problem within the next few of days, then
> you can leave it. If you think it will take longer, then yes I would
> like that commit to be reversed.
>
> Thank you,
>
> John

Non byte aligned skip_bits() is broken, try this:
```
diff --git a/mythtv/libs/libmythtv/bitreader.h
b/mythtv/libs/libmythtv/bitreader.h
index a40707e08f..dd31b4efdd 100644
--- a/mythtv/libs/libmythtv/bitreader.h
+++ b/mythtv/libs/libmythtv/bitreader.h
@@ -47,14 +47,16 @@ class BitReader

     void skip_bits(unsigned n = 1)
     {
-        if (m_cacheSize >= n)
+        if (m_cacheSize > n)
         {
             m_cache <<= n;
             m_cacheSize -= n;
         }
         else
         {
+            n -= m_cacheSize;
             m_cacheSize = 0;
+            m_cache      = 0;
             m_bitIndex += n;
             int quotient = m_bitIndex / CHAR_BIT;
             m_bitIndex %= CHAR_BIT;
```

It seemed to work for me, but I get `HEVCParser PPS Id 0 not valid yet.
Skipping parsing of slice.` in the log even with the switch to BitReader
reverted with your sample.

I thought maybe FFmpeg was doing something to the file, so I switched
the external recorder command to `command="cat
/media/data/htpc/hevc-sample.ts"`, but that had no effect.

Regarding looping,
https://www.mythtv.org/wiki/ExternalRecorder#mythfilerecorder mentions a
--noloop option for mythfilerecorder, but we aren't using that directly.

I will also make the BitReader unit test more comprehensive before
creating a pull request with the above fix.

Regards,

Scott
Re: HVEC frame counting broken [ In reply to ]
On 9/26/22 08:41, Scott Theisen wrote:
> On 9/25/22 21:38, John P Poet wrote:
>> On Sun, Sep 25, 2022 at 8:17 PM Scott Theisen
>> <scott.the.elm@gmail.com> wrote:
>>
>> On 9/25/22 18:48, John P Poet wrote:
>>> On Sun, Sep 25, 2022 at 3:16 PM Scott Theisen
>>> <scott.the.elm@gmail.com> wrote:
>>>
>>>
>>>
>>> On 9/25/22 12:42, John P Poet wrote:
>>>> On Sun, Sep 25, 2022 at 10:40 AM John P Poet
>>>> <jppoet@gmail.com> wrote:
>>>>
>>>> On Sun, Sep 25, 2022 at 10:33 AM Scott Theisen
>>>> <scott.the.elm@gmail.com> wrote:
>>>>
>>>> On 9/25/22 11:43, John P Poet wrote:
>>>>>
>>>>>
>>>>> Thank you Scott. I just uploaded a HEVC sample to
>>>>> dropbox. It should be shared with you.
>>>>
>>>> I have the sample.
>>>>
>>>>>
>>>>> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
>>>>> sps_id: 0
>>>>> width, height: 1920x1088
>>>>> unitsInTick / timeScale: 166817 / 10000000
>>>>>
>>>>> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id,
>>>>> width and height are garbage and the unitsinTick /
>>>>> timeScale are never decoded -- vps_extension_flag
>>>>> is zero.
>>>>>
>>>>> My best guess is that there is an alignment issue
>>>>> and the BitReader that is being passed into
>>>>> HEVCParser::parseSPS is not pointing at the
>>>>> correct position.
>>>>>
>>>>
>>>> OK, but how are you getting the code to execute on
>>>> the sample?  mythcommflag --rebuild something? 
>>>> Adding to Videos and scanning for changes?
>>>>
>>>> Thanks,
>>>>
>>>> Scott
>>>>
>>>>
>>>> I am using an ExternalRecorder
>>>> (https://github.com/jpoet/Magewell2TS). Using the
>>>> mythfilerecorder ExternalRecorder that is packaged with
>>>> Myth should provide the same result. I am pretty sure
>>>> that `mythcommflag --rebuild` results in a different
>>>> code path and I have not tried it.
>>>>
>>>> If you have trouble setting up mythfilerecorder I will
>>>> do that this afternoon and then send you instructions.
>>>>
>>>>
>>>> Actually, I won't. I keep forgetting that I don't currently
>>>> have access to my development machine and my production
>>>> machine will be recording football today. So, that would
>>>> have to wait until tomorrow sometime.
>>>>
>>>> John
>>>
>>> I couldn't figure out how to get mythfilerecorder to work,
>>> so instructions from you, or anyone, would be appreciated.
>>>
>>> Scott
>>>
>>>
>>> I cannot test this until tomorrow, but this should work...
>>>
>>> Put the attached config files in /home/mythtv/etc/ . Modify
>>> externfile.conf so it can find the sample hevc file.
>>>
>>> Create a new "capture card" of type "External (blackbox)
>>> Recorder". For the command path use
>>> "/usr/local/bin/mythexternrecorder --conf
>>> /home/mythtv/etc/externfile.conf". Modify that if your
>>> mythexternrecorder is not in /usr/local/bin.
>>>
>>> You may want/need to create a new source for this capture card.
>>>
>>> You can do a "channel scan" for the new input and it will pick
>>> up the test channel defined in channels.conf. You can then
>>> create a manual record for that channel and it will effectively
>>> "record" the hevc sample file.
>>>
>>>
>>
>> Thanks, that worked, adjusting the paths to the real values. 
>> However, it loops the input file and creates recordings far
>> longer than the specified manual recording duration.
>>
>> I can confirm that parsing is broken. :(
>>
>> Let me know if you want me to open a pull request reverting the
>> change to BitReader, while I investigate.
>>
>> Thanks,
>>
>> Scott
>>
>> PS--Unrelated, but apparently "HEVC" is not a valid registration
>> descriptor according to MythTV:
>> ```
>> 2022-09-25 20:57:29.612931 D [17701/17792] ExternSH
>> mpegstreamdata.cpp:463 (CreatePMTSingleProgram) -
>> MPEGStream[8](0x7f2f840261b0): Program Map Section
>>   PSIP tableID(0x2) length(35) extension(0x1)
>>        version(0) current(1) section(0) last_section(0)
>>        pnum(1) pid(0x1000) pcrpid(0x100)
>>   Stream #0 pid(0x100) type(0x24 video-h265)
>>     Registration Descriptor: 'HEVC' Unknown, see
>> http://www.smpte-ra.org/mpegreg/mpegreg.html
>>   Stream #1 pid(0x101) type(0x81 audio-ac3)
>>     Registration Descriptor: 'AC-3' ATSC audio stream A/52
>> ```
>>
>>
>> Interesting about the HEVC descriptor. I will look into that. I will
>> also look into the looping you mention. I will probably wait until I
>> have direct access to my "dev" machine first, though, since doing
>> that kind of debugging is inconvenient on a live system.
>>
>> If you can figure out the problem within the next few of days, then
>> you can leave it. If you think it will take longer, then yes I would
>> like that commit to be reversed.
>>
>> Thank you,
>>
>> John
>
> Non byte aligned skip_bits() is broken, try this:
> ```
> diff --git a/mythtv/libs/libmythtv/bitreader.h
> b/mythtv/libs/libmythtv/bitreader.h
> index a40707e08f..dd31b4efdd 100644
> --- a/mythtv/libs/libmythtv/bitreader.h
> +++ b/mythtv/libs/libmythtv/bitreader.h
> @@ -47,14 +47,16 @@ class BitReader
>
>      void skip_bits(unsigned n = 1)
>      {
> -        if (m_cacheSize >= n)
> +        if (m_cacheSize > n)
>          {
>              m_cache <<= n;
>              m_cacheSize -= n;
>          }
>          else
>          {
> +            n -= m_cacheSize;
>              m_cacheSize = 0;
> +            m_cache      = 0;
>              m_bitIndex += n;
>              int quotient = m_bitIndex / CHAR_BIT;
>              m_bitIndex %= CHAR_BIT;
> ```
>
> It seemed to work for me, but I get `HEVCParser PPS Id 0 not valid
> yet. Skipping parsing of slice.` in the log even with the switch to
> BitReader reverted with your sample.
>
> I thought maybe FFmpeg was doing something to the file, so I switched
> the external recorder command to `command="cat
> /media/data/htpc/hevc-sample.ts"`, but that had no effect.
>
> Regarding looping,
> https://www.mythtv.org/wiki/ExternalRecorder#mythfilerecorder mentions
> a --noloop option for mythfilerecorder, but we aren't using that directly.
>
> I will also make the BitReader unit test more comprehensive before
> creating a pull request with the above fix.
>
> Regards,
>
> Scott

See Fix BitReader by ulmus-scott · Pull Request #642 · MythTV/mythtv
https://github.com/MythTV/mythtv/pull/642 for my fixes and new unit
tests.  Testing would be appreciated.

Scott
Re: HVEC frame counting broken [ In reply to ]
On Mon, Sep 26, 2022 at 8:39 AM Scott Theisen <scott.the.elm@gmail.com>
wrote:

> On 9/26/22 08:41, Scott Theisen wrote:
>
> On 9/25/22 21:38, John P Poet wrote:
>
> On Sun, Sep 25, 2022 at 8:17 PM Scott Theisen <scott.the.elm@gmail.com>
> wrote:
>
>> On 9/25/22 18:48, John P Poet wrote:
>>
>> On Sun, Sep 25, 2022 at 3:16 PM Scott Theisen <scott.the.elm@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 9/25/22 12:42, John P Poet wrote:
>>>
>>> On Sun, Sep 25, 2022 at 10:40 AM John P Poet <jppoet@gmail.com> wrote:
>>>
>>>> On Sun, Sep 25, 2022 at 10:33 AM Scott Theisen <scott.the.elm@gmail.com>
>>>> wrote:
>>>>
>>>>> On 9/25/22 11:43, John P Poet wrote:
>>>>>
>>>>>
>>>>>
>>>>> Thank you Scott. I just uploaded a HEVC sample to dropbox. It should
>>>>> be shared with you.
>>>>>
>>>>>
>>>>> I have the sample.
>>>>>
>>>>>
>>>>> Without 7b2ac1eeb5, HEVCParser::parseSPS detects the
>>>>> sps_id: 0
>>>>> width, height: 1920x1088
>>>>> unitsInTick / timeScale: 166817 / 10000000
>>>>>
>>>>> With 7b2ac1eeb5, HEVCParser::parseSPS the spd_id, width and height are
>>>>> garbage and the unitsinTick / timeScale are never decoded --
>>>>> vps_extension_flag is zero.
>>>>>
>>>>> My best guess is that there is an alignment issue and the BitReader
>>>>> that is being passed into HEVCParser::parseSPS is not pointing at the
>>>>> correct position.
>>>>>
>>>>>
>>>>> OK, but how are you getting the code to execute on the sample?
>>>>> mythcommflag --rebuild something? Adding to Videos and scanning for
>>>>> changes?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Scott
>>>>>
>>>>
>>>> I am using an ExternalRecorder (https://github.com/jpoet/Magewell2TS).
>>>> Using the mythfilerecorder ExternalRecorder that is packaged with Myth
>>>> should provide the same result. I am pretty sure that `mythcommflag
>>>> --rebuild` results in a different code path and I have not tried it.
>>>>
>>>> If you have trouble setting up mythfilerecorder I will do that this
>>>> afternoon and then send you instructions.
>>>>
>>>
>>> Actually, I won't. I keep forgetting that I don't currently have access
>>> to my development machine and my production machine will be recording
>>> football today. So, that would have to wait until tomorrow sometime.
>>>
>>> John
>>>
>>>
>>> I couldn't figure out how to get mythfilerecorder to work, so
>>> instructions from you, or anyone, would be appreciated.
>>>
>>> Scott
>>>
>>
>> I cannot test this until tomorrow, but this should work...
>>
>> Put the attached config files in /home/mythtv/etc/ . Modify
>> externfile.conf so it can find the sample hevc file.
>>
>> Create a new "capture card" of type "External (blackbox) Recorder". For
>> the command path use "/usr/local/bin/mythexternrecorder --conf
>> /home/mythtv/etc/externfile.conf". Modify that if your mythexternrecorder
>> is not in /usr/local/bin.
>>
>> You may want/need to create a new source for this capture card.
>>
>> You can do a "channel scan" for the new input and it will pick up the
>> test channel defined in channels.conf. You can then create a manual record
>> for that channel and it will effectively "record" the hevc sample file.
>>
>>
>>
>> Thanks, that worked, adjusting the paths to the real values. However, it
>> loops the input file and creates recordings far longer than the specified
>> manual recording duration.
>>
>> I can confirm that parsing is broken. :(
>>
>> Let me know if you want me to open a pull request reverting the change to
>> BitReader, while I investigate.
>>
>> Thanks,
>>
>> Scott
>>
>> PS--Unrelated, but apparently "HEVC" is not a valid registration
>> descriptor according to MythTV:
>> ```
>> 2022-09-25 20:57:29.612931 D [17701/17792] ExternSH
>> mpegstreamdata.cpp:463 (CreatePMTSingleProgram) -
>> MPEGStream[8](0x7f2f840261b0): Program Map Section
>> PSIP tableID(0x2) length(35) extension(0x1)
>> version(0) current(1) section(0) last_section(0)
>> pnum(1) pid(0x1000) pcrpid(0x100)
>> Stream #0 pid(0x100) type(0x24 video-h265)
>> Registration Descriptor: 'HEVC' Unknown, see
>> http://www.smpte-ra.org/mpegreg/mpegreg.html
>> Stream #1 pid(0x101) type(0x81 audio-ac3)
>> Registration Descriptor: 'AC-3' ATSC audio stream A/52
>> ```
>>
>
> Interesting about the HEVC descriptor. I will look into that. I will also
> look into the looping you mention. I will probably wait until I have direct
> access to my "dev" machine first, though, since doing that kind of
> debugging is inconvenient on a live system.
>
> If you can figure out the problem within the next few of days, then you
> can leave it. If you think it will take longer, then yes I would like that
> commit to be reversed.
>
> Thank you,
>
> John
>
>
> Non byte aligned skip_bits() is broken, try this:
> ```
> diff --git a/mythtv/libs/libmythtv/bitreader.h
> b/mythtv/libs/libmythtv/bitreader.h
> index a40707e08f..dd31b4efdd 100644
> --- a/mythtv/libs/libmythtv/bitreader.h
> +++ b/mythtv/libs/libmythtv/bitreader.h
> @@ -47,14 +47,16 @@ class BitReader
>
> void skip_bits(unsigned n = 1)
> {
> - if (m_cacheSize >= n)
> + if (m_cacheSize > n)
> {
> m_cache <<= n;
> m_cacheSize -= n;
> }
> else
> {
> + n -= m_cacheSize;
> m_cacheSize = 0;
> + m_cache = 0;
> m_bitIndex += n;
> int quotient = m_bitIndex / CHAR_BIT;
> m_bitIndex %= CHAR_BIT;
> ```
>
> It seemed to work for me, but I get `HEVCParser PPS Id 0 not valid yet.
> Skipping parsing of slice.` in the log even with the switch to BitReader
> reverted with your sample.
>
> I thought maybe FFmpeg was doing something to the file, so I switched the
> external recorder command to `command="cat
> /media/data/htpc/hevc-sample.ts"`, but that had no effect.
>
> Regarding looping,
> https://www.mythtv.org/wiki/ExternalRecorder#mythfilerecorder mentions a
> --noloop option for mythfilerecorder, but we aren't using that directly.
>
> I will also make the BitReader unit test more comprehensive before
> creating a pull request with the above fix.
>
> Regards,
>
> Scott
>
>
> See Fix BitReader by ulmus-scott · Pull Request #642 · MythTV/mythtv
> https://github.com/MythTV/mythtv/pull/642 for my fixes and new unit
> tests. Testing would be appreciated.
>

Thanks Scott. I will take a look at it this evening.

John