From pb.mythtv at gmail.com Fri Mar 1 20:21:46 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Fri, 1 Mar 2019 15:21:46 -0500 Subject: [mythtv] AVSync2 Improvements In-Reply-To: <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> Message-ID: On 2/28/19 4:10 PM, Mark Spieth wrote: > I watched too last night with the patch using mediacodec however I had > it on old AVSync but the finish early issue still existed which is > strange too. > The "finish early" fix only applies to AVSync2. See comment 1 in the ticket. > Will have to repeat tonight with AVSync2. > > I can make some programs available again if it helps Peter. Use my > previous link but use recordings/1020_20190228080000.ts (news last > night) or some of the other recent ones. The one listed is guaranteed > to show the issue. 1020 is HD and 1021 is SD. I will try that one. Does it always glitch in the same place? I did see a period of stuttery playback during David's recording while I was testing the finish earky fix. The thing is, during the stuttery playback the system was unresponsive to the remote. This indicates that something on the system was pre-empting mythfrontend. What springs to mind is that it may have been doing a java full garbage collect operation. My experience with java (non-android) is you need to be careful to avoid full garbage collect operations during a real-time process like playback. Mediacodec decoding goes through java code so it may be a possibility. I don't know how you adjust the garbage collect settings on android, on regular systems it is via parameters on the java command line. Do you notice that it is unresponsive to the remote while the stuttering takes place? Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at digivation.com.au Fri Mar 1 22:28:52 2019 From: mark at digivation.com.au (Mark Spieth) Date: Sat, 2 Mar 2019 09:28:52 +1100 Subject: [mythtv] AVSync2 Improvements In-Reply-To: References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> Message-ID: <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> On 3/2/2019 7:21 AM, Peter Bennett wrote: > > > On 2/28/19 4:10 PM, Mark Spieth wrote: >> I watched too last night with the patch using mediacodec however I >> had it on old AVSync but the finish early issue still existed which >> is strange too. >> > The "finish early" fix only applies to AVSync2. See comment 1 in the > ticket. >> Will have to repeat tonight with AVSync2. >> >> I can make some programs available again if it helps Peter. Use my >> previous link but use recordings/1020_20190228080000.ts (news last >> night) or some of the other recent ones. The one listed is guaranteed >> to show the issue. 1020 is HD and 1021 is SD. > > I will try that one. Does it always glitch in the same place? I dont see any glitches at all during playback of any of these programs. The time is just wrong but this also does not happen linearly. My test last night with AVSync2 worked well except I had mythcommflag suck 21g out of my ram bringing the whole backend to a grinding halt until I deleted the errant process, but thats another/different problem. Playback on the shield paused at that period but the timestamp was correct at that point. I thought originally that the deletemap search for the timestamp had an infinite loop but I suspect that is wrong, but more testing will ensue today. There are others too. anything with a channel number in 10xx is a dvbt recording. I have left some around for this purpose (testing/validation). > > I did see a period of stuttery playback during David's recording while > I was testing the finish earky fix. The thing is, during the stuttery > playback the system was unresponsive to the remote. This indicates > that something on the system was pre-empting mythfrontend. > I had a different problem the other day where with mediacodec with both AVSync and AVSync2, both exhibited a play 1sec then skip 1 sec type behaviour which was really weird. Unfortunately I deleted that without thinking after playing successfuly with SW decode. This may be the same as the stuttery playback but not sure. Only ever happened once, on a program I watch weekly. > What springs to mind is that it may have been doing a java full > garbage collect operation. My experience with java (non-android) is > you need to be careful to avoid full garbage collect operations during > a real-time process like playback. Mediacodec decoding goes through > java code so it may be a possibility. I don't know how you adjust the > garbage collect settings on android, on regular systems it is via > parameters on the java command line. I dont either, but if this was a problem, other apps would have seen this too. Unlikely cause. > > Do you notice that it is unresponsive to the remote while the > stuttering takes place? > No. But I have only seen it once. Mark From pb.mythtv at gmail.com Fri Mar 1 23:50:08 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Fri, 1 Mar 2019 18:50:08 -0500 Subject: [mythtv] AVSync2 Improvements In-Reply-To: <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> Message-ID: <25791414-796c-d445-5305-bf4594c5dabd@gmail.com> On 3/1/19 5:28 PM, Mark Spieth wrote: > On 3/2/2019 7:21 AM, Peter Bennett wrote: >> >> >> On 2/28/19 4:10 PM, Mark Spieth wrote: >>> I watched too last night with the patch using mediacodec however I >>> had it on old AVSync but the finish early issue still existed which >>> is strange too. >>> >> The "finish early" fix only applies to AVSync2. See comment 1 in the >> ticket. >>> Will have to repeat tonight with AVSync2. >>> >>> I can make some programs available again if it helps Peter. Use my >>> previous link but use recordings/1020_20190228080000.ts (news last >>> night) or some of the other recent ones. The one listed is >>> guaranteed to show the issue. 1020 is HD and 1021 is SD. >> >> I will try that one. Does it always glitch in the same place? > > I dont see any glitches at all during playback of any of these > programs. The time is just wrong but this also does not happen > linearly. My test last night with AVSync2 worked well except I had > mythcommflag suck 21g out of my ram bringing the whole backend to a > grinding halt until I deleted the errant process, but thats > another/different problem. Playback on the shield paused at that > period but the timestamp was correct at that point. I thought > originally that the deletemap search for the timestamp had an infinite > loop but I suspect that is wrong, but more testing will ensue today. > > There are others too. anything with a channel number in 10xx is a dvbt > recording. I have left some around for this purpose (testing/validation). > >> >> I did see a period of stuttery playback during David's recording >> while I was testing the finish earky fix. The thing is, during the >> stuttery playback the system was unresponsive to the remote. This >> indicates that something on the system was pre-empting mythfrontend. >> > I had a different problem the other day where with mediacodec with > both AVSync and AVSync2, both exhibited a play 1sec then skip 1 sec > type behaviour which was really weird. Unfortunately I deleted that > without thinking after playing successfuly with SW decode. This may be > the same as the stuttery playback but not sure. Only ever happened > once, on a program I watch weekly. > >> What springs to mind is that it may have been doing a java full >> garbage collect operation. My experience with java (non-android) is >> you need to be careful to avoid full garbage collect operations >> during a real-time process like playback. Mediacodec decoding goes >> through java code so it may be a possibility. I don't know how you >> adjust the garbage collect settings on android, on regular systems it >> is via parameters on the java command line. > I dont either, but if this was a problem, other apps would have seen > this too. Unlikely cause. >> >> Do you notice that it is unresponsive to the remote while the >> stuttering takes place? >> > No. But I have only seen it once. > > Mark > > I tried your news program at 1.5x. At 6:42 the audio became way out of sync with the video. Repeating the test and going to 6:42 did not show it again, so it is not something special in the video causing it.? I will try it again and see if I can track down the problem. It may be something that goes away when we have direct rendering. It could be related to the fact that some 75 frames per second are being copied into memory. Even with some frames being skipped on display to keep up, it remains that they are still all copied to memory. I had thought of inserting some code into the decoder so that frames that are destined to be skipped are not copied to memory, but if we get direct rendering that would become moot, so I decided to wait for direct rendering. Peter From mark at digivation.com.au Sat Mar 2 02:32:20 2019 From: mark at digivation.com.au (Mark Spieth) Date: Sat, 2 Mar 2019 13:32:20 +1100 Subject: [mythtv] AVSync2 Improvements In-Reply-To: <25791414-796c-d445-5305-bf4594c5dabd@gmail.com> References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> <25791414-796c-d445-5305-bf4594c5dabd@gmail.com> Message-ID: <00a6b027-5b49-1448-ca11-486a6a7747e2@digivation.com.au> On 3/2/2019 10:50 AM, Peter Bennett wrote: > > > On 3/1/19 5:28 PM, Mark Spieth wrote: >> On 3/2/2019 7:21 AM, Peter Bennett wrote: >>> >>> >>> On 2/28/19 4:10 PM, Mark Spieth wrote: >>>> I watched too last night with the patch using mediacodec however I >>>> had it on old AVSync but the finish early issue still existed which >>>> is strange too. >>>> >>> The "finish early" fix only applies to AVSync2. See comment 1 in the >>> ticket. >>>> Will have to repeat tonight with AVSync2. >>>> >>>> I can make some programs available again if it helps Peter. Use my >>>> previous link but use recordings/1020_20190228080000.ts (news last >>>> night) or some of the other recent ones. The one listed is >>>> guaranteed to show the issue. 1020 is HD and 1021 is SD. >>> >>> I will try that one. Does it always glitch in the same place? >> >> I dont see any glitches at all during playback of any of these >> programs. The time is just wrong but this also does not happen >> linearly. My test last night with AVSync2 worked well except I had >> mythcommflag suck 21g out of my ram bringing the whole backend to a >> grinding halt until I deleted the errant process, but thats >> another/different problem. Playback on the shield paused at that >> period but the timestamp was correct at that point. I thought >> originally that the deletemap search for the timestamp had an >> infinite loop but I suspect that is wrong, but more testing will >> ensue today. >> >> There are others too. anything with a channel number in 10xx is a >> dvbt recording. I have left some around for this purpose >> (testing/validation). >> >>> >>> I did see a period of stuttery playback during David's recording >>> while I was testing the finish earky fix. The thing is, during the >>> stuttery playback the system was unresponsive to the remote. This >>> indicates that something on the system was pre-empting mythfrontend. >>> >> I had a different problem the other day where with mediacodec with >> both AVSync and AVSync2, both exhibited a play 1sec then skip 1 sec >> type behaviour which was really weird. Unfortunately I deleted that >> without thinking after playing successfuly with SW decode. This may >> be the same as the stuttery playback but not sure. Only ever happened >> once, on a program I watch weekly. >> >>> What springs to mind is that it may have been doing a java full >>> garbage collect operation. My experience with java (non-android) is >>> you need to be careful to avoid full garbage collect operations >>> during a real-time process like playback. Mediacodec decoding goes >>> through java code so it may be a possibility. I don't know how you >>> adjust the garbage collect settings on android, on regular systems >>> it is via parameters on the java command line. >> I dont either, but if this was a problem, other apps would have seen >> this too. Unlikely cause. >>> >>> Do you notice that it is unresponsive to the remote while the >>> stuttering takes place? >>> >> No. But I have only seen it once. >> >> Mark >> >> > I tried your news program at 1.5x. At 6:42 the audio became way out of > sync with the video. Repeating the test and going to 6:42 did not show > it again, so it is not something special in the video causing it.? I > will try it again and see if I can track down the problem. > > It may be something that goes away when we have direct rendering. It > could be related to the fact that some 75 frames per second are being > copied into memory. Even with some frames being skipped on display to > keep up, it remains that they are still all copied to memory. I had > thought of inserting some code into the decoder so that frames that > are destined to be skipped are not copied to memory, but if we get > direct rendering that would become moot, so I decided to wait for > direct rendering. The time issue happens at the same rate irrespective of the playback speed. I suspect your problem may be an NTP twiddle which would stuff things right up since I think only video uses system time. Thats why I implemented QElapseTimer to do timing since it uses monotonic CPU time. I can post a patch if you like. Also I have a stuttering program again. Its recording right now. When complete it will be 6.5h but is only 25m in ATM. I can keep it if you want but normally I delete straight after watching, which I'm doing now. 1013_20190302020000.ts Stuttering occurs right at the start of the program with mediacodec decoder. SW dec is fine. Either avsync method exhibits this so its mediacodec related. HTH Mark From pb.mythtv at gmail.com Sat Mar 2 15:30:16 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Sat, 2 Mar 2019 10:30:16 -0500 Subject: [mythtv] AVSync2 Improvements In-Reply-To: <00a6b027-5b49-1448-ca11-486a6a7747e2@digivation.com.au> References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> <25791414-796c-d445-5305-bf4594c5dabd@gmail.com> <00a6b027-5b49-1448-ca11-486a6a7747e2@digivation.com.au> Message-ID: <90429a03-6cbf-c1c5-79ef-fa95ee51c080@gmail.com> On 3/1/19 9:32 PM, Mark Spieth wrote: > The time issue happens at the same rate irrespective of the playback > speed. I suspect your problem may be an NTP twiddle which would stuff > things right up since I think only video uses system time. Thats why I > implemented QElapseTimer to do timing since it uses monotonic CPU > time. I can post a patch if you like. > Please post a patch or email it. > Also I have a stuttering program again. Its recording right now. When > complete it will be 6.5h but is only 25m in ATM. I can keep it if you > want but normally I delete straight after watching, which I'm doing now. > > 1013_20190302020000.ts > > Stuttering occurs right at the start of the program with mediacodec > decoder. SW dec is fine. Either avsync method exhibits this so its > mediacodec related. > I am hoping that the direct render fixes it. Mark K said that he will be looking into direct render. Anyway I will download some of that file and see if I can do anything to understand what is happening, Peter From mark.kendall at gmail.com Sat Mar 2 15:58:46 2019 From: mark.kendall at gmail.com (Mark Kendall) Date: Sat, 2 Mar 2019 15:58:46 +0000 Subject: [mythtv] AVSync2 Improvements In-Reply-To: <90429a03-6cbf-c1c5-79ef-fa95ee51c080@gmail.com> References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> <25791414-796c-d445-5305-bf4594c5dabd@gmail.com> <00a6b027-5b49-1448-ca11-486a6a7747e2@digivation.com.au> <90429a03-6cbf-c1c5-79ef-fa95ee51c080@gmail.com> Message-ID: On Sat, Mar 2, 2019, 3:31 PM Peter Bennett wrote: > > Stuttering occurs right at the start of the program with mediacodec > > decoder. SW dec is fine. Either avsync method exhibits this so its > > mediacodec related. > > > I am hoping that the direct render fixes it. Mark K said that he will be > looking into direct render. Anyway I will download some of that file and > see if I can do anything to understand what is happening, > Has anyone tried increasing the number of mediacodec video buffers? Its only 8 at the moment. I had similar problems with VideoToolBox decoding this week and increasing the buffer count was the key. 8 gives you very little headroom for the simplest of system glitches. Direct render is getting there - only problem is it crashes as soon as it tries to display anything:) Regards, Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at digivation.com.au Sat Mar 2 22:03:36 2019 From: mark at digivation.com.au (Mark Spieth) Date: Sun, 3 Mar 2019 09:03:36 +1100 Subject: [mythtv] AVSync2 Improvements In-Reply-To: References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> <25791414-796c-d445-5305-bf4594c5dabd@gmail.com> <00a6b027-5b49-1448-ca11-486a6a7747e2@digivation.com.au> <90429a03-6cbf-c1c5-79ef-fa95ee51c080@gmail.com> Message-ID: <9195d292-f39f-42b9-3899-a11c0a600369@digivation.com.au> On 3/3/2019 2:58 AM, Mark Kendall wrote: > > > On Sat, Mar 2, 2019, 3:31 PM Peter Bennett > wrote: > > > Stuttering occurs right at the start of the program with mediacodec > > decoder. SW dec is fine. Either avsync method exhibits this so its > > mediacodec related. > > > I am hoping that the direct render fixes it. Mark K said that he > will be > looking into direct render. Anyway I will download some of that > file and > see if I can do anything to understand what is happening, > > > Has anyone tried increasing the number of mediacodec video buffers? > Its only 8 at the moment. I had similar problems with VideoToolBox > decoding this week and increasing the buffer count was the key. 8 > gives you very little headroom for the simplest of system glitches. > > Direct render is getting there - only problem is it crashes as soon as > it tries to display anything:) > Mark, I have tried to find this but failed :-(. where is this constant/setting? I would like to try it as I suspect it fixes the timing issue we are currently seeing with mediacodec. Thanks Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From pb.mythtv at gmail.com Sat Mar 2 22:11:08 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Sat, 2 Mar 2019 17:11:08 -0500 Subject: [mythtv] AVSync2 Improvements In-Reply-To: References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> <25791414-796c-d445-5305-bf4594c5dabd@gmail.com> <00a6b027-5b49-1448-ca11-486a6a7747e2@digivation.com.au> <90429a03-6cbf-c1c5-79ef-fa95ee51c080@gmail.com> Message-ID: <94bb7b27-f806-b2f8-ffad-a078b6359712@gmail.com> On 3/2/19 10:58 AM, Mark Kendall wrote: > > > On Sat, Mar 2, 2019, 3:31 PM Peter Bennett > wrote: > > > Stuttering occurs right at the start of the program with mediacodec > > decoder. SW dec is fine. Either avsync method exhibits this so its > > mediacodec related. > > > I am hoping that the direct render fixes it. Mark K said that he > will be > looking into direct render. Anyway I will download some of that > file and > see if I can do anything to understand what is happening, > > > Has anyone tried increasing the number of mediacodec video buffers? > Its only 8 at the moment. I had similar problems with VideoToolBox > decoding this week and increasing the buffer count was the key. 8 > gives you very little headroom for the simplest of system glitches. > > Direct render is getting there - only problem is it crashes as soon as > it tries to display anything:) > > Regards, Mark > > _______________________________________________ > I tried the video that gives the problem. It is H264 interlaced. Normally, mediacodec on shield should deinterlace it and hand it to MythTV as progressive. MythTV is seeing this as progressive switching to interlaced and back to progressive again about once every second. This causes the OpenGL rendering and deinterlacing to be re-initialized twice every second. It is not surprising that this results in jerky playback. I will trace through it and see whether ffmpeg is actually switching it back and forth between interlaced and progressive, and whether anything can be done about it. Regarding the video buffers - I had to set that low value, otherwise playback would be terminated by android on the shield. Android has very restrictive memory usage rules, and does not hesitate to shut down any process that uses more than it thinks is reasonable. 8 buffers seemed to be the best value that worked well. I do not think the video buffers are the cause of the jerkiness. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From pb.mythtv at gmail.com Sat Mar 2 22:35:37 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Sat, 2 Mar 2019 17:35:37 -0500 Subject: [mythtv] AVSync2 Improvements In-Reply-To: <9195d292-f39f-42b9-3899-a11c0a600369@digivation.com.au> References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> <25791414-796c-d445-5305-bf4594c5dabd@gmail.com> <00a6b027-5b49-1448-ca11-486a6a7747e2@digivation.com.au> <90429a03-6cbf-c1c5-79ef-fa95ee51c080@gmail.com> <9195d292-f39f-42b9-3899-a11c0a600369@digivation.com.au> Message-ID: On 3/2/19 5:03 PM, Mark Spieth wrote: > On 3/3/2019 2:58 AM, Mark Kendall wrote: >> >> >> On Sat, Mar 2, 2019, 3:31 PM Peter Bennett > > wrote: >> >> > Stuttering occurs right at the start of the program with >> mediacodec >> > decoder. SW dec is fine. Either avsync method exhibits this so its >> > mediacodec related. >> > >> I am hoping that the direct render fixes it. Mark K said that he >> will be >> looking into direct render. Anyway I will download some of that >> file and >> see if I can do anything to understand what is happening, >> >> >> Has anyone tried increasing the number of mediacodec video buffers? >> Its only 8 at the moment. I had similar problems with VideoToolBox >> decoding this week and increasing the buffer count was the key. 8 >> gives you very little headroom for the simplest of system glitches. >> >> Direct render is getting there - only problem is it crashes as soon >> as it tries to display anything:) >> > Mark, > > I have tried to find this but failed :-(. where is this > constant/setting? I would like to try it as I suspect it fixes the > timing issue we are currently seeing with mediacodec. > > Thanks > > Mark > > It is in VideoOutputOpenGL::CreateBuffers - however as I mentioned in my previous email, it seems the problem is with mis-detection of interlaced versus progressive, and changing the video buffers will likely cause android to terminate the app -------------- next part -------------- An HTML attachment was scrubbed... URL: From pb.mythtv at gmail.com Sun Mar 3 22:09:13 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Sun, 3 Mar 2019 17:09:13 -0500 Subject: [mythtv] AVSync2 Improvements In-Reply-To: References: <20190216220045.GA15040@opus.istwok.net> <20190217190301.GC32295@opus.istwok.net> <0094a5da-a983-1383-5552-283280844379@gmail.com> <20190219201354.GA18843@opus.istwok.net> <20190225000246.GB10199@opus.istwok.net> <7c43104c-d4b2-30e4-6bea-e167fe95ef5e@gmail.com> <20190225173248.GA23733@opus.istwok.net> <175eb86c-3e02-5614-1260-1d697d924479@gmail.com> <20190226020743.GB15686@opus.istwok.net> <20190228184343.GA516@opus.istwok.net> <4d5029a7-94bd-49a1-c7b4-4ee51ebc0dce@digivation.com.au> <4853a74e-4d75-3020-3569-5df0032d3af1@digivation.com.au> <25791414-796c-d445-5305-bf4594c5dabd@gmail.com> <00a6b027-5b49-1448-ca11-486a6a7747e2@digivation.com.au> <90429a03-6cbf-c1c5-79ef-fa95ee51c080@gmail.com> <9195d292-f39f-42b9-3899-a11c0a600369@digivation.com.au> Message-ID: On 3/2/19 5:35 PM, Peter Bennett wrote: > > > On 3/2/19 5:03 PM, Mark Spieth wrote: >> On 3/3/2019 2:58 AM, Mark Kendall wrote: >>> >>> >>> On Sat, Mar 2, 2019, 3:31 PM Peter Bennett >> > wrote: >>> >>> > Stuttering occurs right at the start of the program with >>> mediacodec >>> > decoder. SW dec is fine. Either avsync method exhibits this so >>> its >>> > mediacodec related. >>> > >>> I am hoping that the direct render fixes it. Mark K said that he >>> will be >>> looking into direct render. Anyway I will download some of that >>> file and >>> see if I can do anything to understand what is happening, >>> >>> >>> Has anyone tried increasing the number of mediacodec video buffers? >>> Its only 8 at the moment. I had similar problems with VideoToolBox >>> decoding this week and increasing the buffer count was the key. 8 >>> gives you very little headroom for the simplest of system glitches. >>> >>> Direct render is getting there - only problem is it crashes as soon >>> as it tries to display anything:) >>> >> Mark, >> >> I have tried to find this but failed :-(. where is this >> constant/setting? I would like to try it as I suspect it fixes the >> timing issue we are currently seeing with mediacodec. >> >> Thanks >> >> Mark >> >> > > It is in VideoOutputOpenGL::CreateBuffers - however as I mentioned in > my previous email, it seems the problem is with mis-detection of > interlaced versus progressive, and changing the video buffers will > likely cause android to terminate the app I found the problem with the car racing video from Mark - misdetection of frame rate - see patch in ticket https://code.mythtv.org/trac/ticket/13419 Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From angela.schmid at wolke7.net Sun Mar 10 17:46:20 2019 From: angela.schmid at wolke7.net (Angela) Date: Sun, 10 Mar 2019 18:46:20 +0100 Subject: [mythtv] MySQL 5.7 / DATETIME: '000-00-00' problem (1) Message-ID: <026901d4d769$2c71cb20$85556160$@wolke7.net> Installed a new Ubuntu 18.04 server, using unchanged Mythtv 29.0-fixes. mysql-server, 5.7.25-0ubuntu0.18.04.2 I make frequently a dump of videometadata in a table with the same layout and encountered the following error: Incorrect date value: '0000-00-00' for column 'releasedate' Since mysql 5.7 Datetime does not allow '000-00-00' to be set. This could be fixed with removing STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE from sql_mode in mysqld settings. Instead of removing/ignoring warnings/errors, will Mythtv correctly set NULL values instead of '000-00-00' in the future? Is this addressed? Cheers Angela From angela.schmid at wolke7.net Sun Mar 10 17:46:22 2019 From: angela.schmid at wolke7.net (Angela) Date: Sun, 10 Mar 2019 18:46:22 +0100 Subject: [mythtv] MySQL 5.7 / DATETIME / Python Bindings: timezone problem (2) Message-ID: <026a01d4d769$2cc0ae70$86420b50$@wolke7.net> Installed a new Ubuntu 18.04 server, using unchanged Mythtv 29.0-fixes. mysql-server, 5.7.25-0ubuntu0.18.04.2 I am using lossless_cut with the Python bindings and noticed the following problem: /usr/local/lib/python2.7/dist-packages/MythTV/_conn_mysqldb.py:72: Warning: (1292L, u"Incorrect datetime value: '2016-12-27 18:50:00+01:00' for column 'starttime' at row 1") Datetime only have a fraction, not a timezone. This seems to generate warnings with newer mysql. Setting TZ=UTC, a timezone part is still added to the query, changed the warning in /usr/local/lib/python2.7/dist-packages/MythTV/_conn_mysqldb.py:72: Warning: (1292L, u"Incorrect datetime value: '2016-12-27 17:50:00+00:00' for column 'starttime' at row 1") default-time-zone = 'UTC', in the mysqld configuration produced the same warning. Added some debugging which shows that a TZ is set on the recorded.starttime variable and used to setup following queries. ('starttime', datetime(2016, 12, 27, 18, 50, tzinfo=)) ('query:', u"SELECT genre FROM `programgenres` WHERE chanid=10262 AND starttime='2016-12-27 18:50:00+01:00' LIMIT 1;") Although a warning, only results are delivered when TZ=UTC is used (the TZ is still somehow stripped); matching the Mythtv datetimes in UTC. Would it not be better the backend API sends datatimes without TZ (also in the bindings)? Leaving localization to the client. Other ideas to fix this kind of problem? Cheers Angela -------------- next part -------------- An HTML attachment was scrubbed... URL: From pb.mythtv at gmail.com Tue Mar 12 01:56:28 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Mon, 11 Mar 2019 21:56:28 -0400 Subject: [mythtv] 2019-render and Fire TV Message-ID: <64c6ceb2-65c3-318d-7a02-668648755f53@gmail.com> I tried disabling the "OpenGL extra stage" switch. It was previously causing blank screen intermittently on Fire tv 4k. I am now unable to recreate the blank screen with master branch or with render branch. That does not say it has definitely been fixed. I will see if I can do more extensive testing. Fire Stick (non-4K) using mediacodec with opengl-hw - mpeg2 interlaced - plays ok but a bit jerky h264 720p - hangs. I see the first frame, then nothing more and does not respond to remote. Fire Stick 4k mpeg2 interlaced was never able to play using mediacodec, and that problem still exists with mediacodec decode. using mediacodec & opengl-hw: mpeg2 - very jerky & messages "MediaCodecInterop: Timed out waiting for frame update" about 1 per second. h264 - 720p - 1280x720 picture shows in top Left hand part of screen (it seems picture has not been expanded to fill 1920x1080). Messages "MediaCodecInterop: Timed out waiting for frame update" about 10 per second. h264 1080i - I see tearing of the picture, plus the fact that there is no deinterlace. Peter From klaas.de.waal at gmail.com Thu Mar 14 15:08:06 2019 From: klaas.de.waal at gmail.com (Klaas de Waal) Date: Thu, 14 Mar 2019 16:08:06 +0100 Subject: [mythtv] Support for multiple delivery systems Message-ID: I've just added a patch for today's master to ticket #13014 that implements delivery system selection for DVB-tuners that can do DVB-T, DVB-T2 or DVB-C. This is a first version, for testing only; there is a lot of debug output and it uses column displayname of database table capturecard. This allows testing on today's master without the need to modify the database. The full solution will include a new column deliverysystem. N.B. The names presented for the delivery systems have been changed to be the same as what is used in libdvbv5 and in the dvb-fe-tool; for instance, DVB-T, DVB-T2 and DVBCAC have been changed to DVBT, DVBT2 and DVBC/ANNEX_A. N.B. This is a minimal implementation, to keep the size of the patch small and to make review possible. This is thus not the complete change from DVBv3 to DVBv5; that will be done in ticket #12638. I would appreciate feedback on how this solution works on other people's systems and also how the implementation can be improved so that I can prepare a full solution to be integrated in master. Thanks, Klaas. From mike.bibbings at gmail.com Thu Mar 14 20:35:39 2019 From: mike.bibbings at gmail.com (Mike Bibbings) Date: Thu, 14 Mar 2019 20:35:39 +0000 Subject: [mythtv] Support for multiple delivery systems In-Reply-To: References: Message-ID: <693115b0-645e-507b-da90-7e8d99141c73@gmail.com> On 14/03/2019 15:08, Klaas de Waal wrote: > I've just added a patch for today's master to ticket #13014 that > implements delivery system selection for DVB-tuners that can do DVB-T, > DVB-T2 or DVB-C. This is a first version, for testing only; there is a > lot of debug output and it uses column displayname of database table > capturecard. This allows testing on today's master without the need to > modify the database. The full solution will include a new column > deliverysystem. > > N.B. The names presented for the delivery systems have been changed to > be the same as what is used in libdvbv5 and in the dvb-fe-tool; for > instance, DVB-T, DVB-T2 and DVBCAC have been changed to DVBT, DVBT2 > and DVBC/ANNEX_A. > N.B. This is a minimal implementation, to keep the size of the patch > small and to make review possible. This is thus not the complete > change from DVBv3 to DVBv5; that will be done in ticket #12638. > > I would appreciate feedback on how this solution works on other > people's systems and also how the implementation can be improved so > that I can prepare a full solution to be integrated in master. > > Thanks, > Klaas. I have done some quick tests and updated the ticket https://code.mythtv.org/trac/ticket/13014 Mike From pb.mythtv at gmail.com Thu Mar 21 15:29:35 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Thu, 21 Mar 2019 11:29:35 -0400 Subject: [mythtv] Extra stage setting Message-ID: <85048740-6b5d-4652-7794-5634a8c6cef1@gmail.com> Mark I have tested for a week using master branch with "extra stage opengl" disabled and there has been no problem. It seems whatever caused the problem is fixed. Peter From mark.kendall at gmail.com Fri Mar 22 13:55:19 2019 From: mark.kendall at gmail.com (Mark Kendall) Date: Fri, 22 Mar 2019 13:55:19 +0000 Subject: [mythtv] Extra stage setting In-Reply-To: <85048740-6b5d-4652-7794-5634a8c6cef1@gmail.com> References: <85048740-6b5d-4652-7794-5634a8c6cef1@gmail.com> Message-ID: Thanks Peter, I'll remove the setting in the render branch. Regards Mark On Thu, Mar 21, 2019, 3:29 PM Peter Bennett wrote: > Mark > > I have tested for a week using master branch with "extra stage opengl" > disabled and there has been no problem. It seems whatever caused the > problem is fixed. > > Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pb.mythtv at gmail.com Fri Mar 29 18:55:51 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Fri, 29 Mar 2019 14:55:51 -0400 Subject: [mythtv] OpenGL questions Message-ID: Hi Mark I am trying to learn OpenGL by going through some tutorials and examples. Would you mind answering a basic question? Which version or versions of OpenGL and GLSL do we target in MythTV? It looks like you do not use the #version specifier. Then OpenGL assumes it is using GLSL version 1.10 from 2004 (OpenGL 2.0) and OpenGL ES assumes GLSL version 1.00 from 2009 (OpenGL ES 2.0). Is that what we are using? Do we build everything to be compatible with both of these? Those versions seem like ancient history? Any tips you may have regarding OpenGL for a beginner would be welcome. Regards Peter From mark.kendall at gmail.com Sun Mar 31 09:56:14 2019 From: mark.kendall at gmail.com (Mark Kendall) Date: Sun, 31 Mar 2019 10:56:14 +0100 Subject: [mythtv] OpenGL questions In-Reply-To: References: Message-ID: On Fri, 29 Mar 2019 at 18:55, Peter Bennett wrote: > > Hi Mark1 - general OpenGL state management > > I am trying to learn OpenGL by going through some tutorials and > examples. Would you mind answering a basic question? > > Which version or versions of OpenGL and GLSL do we target in MythTV? > > It looks like you do not use the #version specifier. Then OpenGL assumes > it is using GLSL version 1.10 from 2004 (OpenGL 2.0) and OpenGL ES > assumes GLSL version 1.00 from 2009 (OpenGL ES 2.0). Is that what we are > using? Do we build everything to be compatible with both of these? Those > versions seem like ancient history? Hi Peter, We essentially target the lowest common denominator. At the moment, that is OpenGL 2.0/ ES 2.0. There are a number of reasons for this - all referencing the devel/2019-render branch, where the code has obviously moved on considerably:- 1 - In general, we do not need anything above and beyond those versions. 2 - There are still platforms that only support those versions (e.g. Pi, some mesa drivers) 3 - Qt provides QOpenGLContext, QOpenGLFunctions etc that provide a simple/convenient wrapper around a common subset of GL2.0 and GL ES2.0 functionality. On point 1, our OpenGL needs are quite basic. For the most part we only want to render textures on screen. We are not interested in occlusion culling, geometry shaders, instancing and a hundred and one more modern, advanced features that newer versions offer and which are largely targeted at gaming or CAD demands (and indeed a hundred and one old, basic features that are irrelevant). Whilst GLSL has evolved, its core functionality is unchanged and a lot of the incompatibility between older and newer versions is syntax rather than functionality (for our uses at least). Yes, we use some more 'modern' functionality where available but generally this is available by extension on the older versions anyway. The raspberry pi driver is rapidly becoming the real exception to this as it has, by a large margin, the most limited feature set (and performance) of anything I've seen for a couple of years. That said, I'm quite sure there are gains to be had from tapping into some of the newer features but I think, once the render branch has stabilised (and is merged), the next effort should be Vulkan support. > Any tips you may have regarding OpenGL for a beginner would be welcome. Focusing purely on the MythTV use case, there are 4 areas of core functionality that are relevant:- 1 - General OpenGL state management - mostly handled in MythRenderOpenGL. viewport management, texture binding, shader binding, blend state etc etc. All fairly standard. 2 - vertex data - very simple for our use case - simply upload enough vertex data to render a square/rectangle. 3 - textures - core to both video and UI. Essentially pretty standard for UI (and now largely handled by Qt) with some more demanding use cases for video. A performance bottleneck. 4 - shaders - obviously key to any modern OpenGL code. You'll see though that for the most part our shaders are extremely simple - especially for just rendering an RGBA texture on screen. - the circle shaders etc are slighly more complicated as are the deinterlacers. I'd recommend just focusing on GL2.0/ES2.0 to start with. Trying to cross-reference GLSL4.6 shaders will just give you headaches:) Everything then just builds on those basics. I'd also highly recommend installing apitrace (and qapitrace - the gui part). This will produce a trace of all of the OpenGL/GLX/EGL calls that an app makes on a frame by frame basis. If you run mythtv from the render branch with -v gpu logging, it will also insert debug markers showing you which parts of the mythtv render code are making those calls. At its most basic, the trace will give you a very neat insight into how the OpenGL code is working. It won't however provide much help with what's going on inside a shader... I hope this helps. Any questions, just ask. regards Mark From pb.mythtv at gmail.com Sun Mar 31 18:41:11 2019 From: pb.mythtv at gmail.com (Peter Bennett) Date: Sun, 31 Mar 2019 14:41:11 -0400 Subject: [mythtv] OpenGL questions In-Reply-To: References: Message-ID: On 3/31/19 5:56 AM, Mark Kendall wrote: Hi Mark Thank you for the detailed reply. I am building and testing some of the sample OpenGL programs., and I am using apitrace to see what is going on. One interesting thing I found - A sample program that uses QOpenGLWidget to display a window with just a triangle does hundreds of OpenGL calls that are not generated by the user code. Apart from displaying the triangle, it uses two textures and hundreds of other calls, plus some extra shaders that are not in the user code. On the other hand a sample that uses QWindow and QOpenGLFunctions to display a triangle does not create any extra textures or shaders and seems to only generate the OpenGL code that is requested by the user code. I have not yet tried QOpenGLWindow, I don't know how it compares to QWindow or OpenGLWidget. Regards Peter