[mythtv-users] Help with playback issue on recordings from a single channel

Sat Dec 25 21:04:22 UTC 2021

On 25/12/2021 20:19, John Pilkington wrote:
> On 25/12/2021 19:31, Vincent Poore via mythtv-users wrote:
>> I tried converting the codecs using the command you supplied
>> ffmpeg -i temp.ts -vcodec libx264 -crf 24 -tune film -acodec copy 
>> (mythrecname).ts
>>
>> Surprise!   That locked up my machine after it had gotten about 5 
>> minutes in.
>>
>> ffprobe reported these streams in that file.
>> Input #0, mpegts, from '1504_20211224010000.original.ts':
>>    Duration: 00:34:27.45, start: 22646.908422, bitrate: 7758 kb/s
>>    Program 1
>>      Stream #0:0[0x760]: Video: mpeg2video (Main) ([2][0][0][0] / 
>> 0x0002), yuv420p(tv, top first), 1920x1080 [SAR 1:1 DAR 16:9], Closed 
>> Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
>>      Stream #0:1[0x761](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 
>> Hz, 5.1(side), fltp, 384 kb/s
>>      Stream #0:2[0x762](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 
>> Hz, stereo, fltp, 128 kb/s
>>
>>
>>
>> On Friday, December 24, 2021, 07:19:12 PM MST, glen <glenb at glenb.net> 
>> wrote:
>>
>>
>> On Sat, 2021-12-25 at 01:25 +0000, Vincent Poore via mythtv-users wrote:
>>> I've been living with and frustrated by a problem with recordings 
>>> from my local CBS broadcast channel.
>>>
>>> It all started when my local station added a new digital sub-channel. 
>>>  I know this because my problem started on March 1st and a call to 
>>> the station engineer confirmed changes were made to the broadcast 
>>> signal early that Sunday morning. He says, "Everything in this 
>>> encoding scheme is industry standard, so I wouldn’t expect there to 
>>> be any problem decoding it with commercial equipment."  I'm not 
>>> technical enough to determine what has changed that would give mythtv 
>>> so much trouble.  Here are the symptoms:
>>>
>>> Prior to the change, I used VDPAU High Quality Video Playback 
>>> Profile.   After the change, this profile on the bad channel will 
>>> eventually cause my machine to lock up.  It starts with some serious 
>>> macro blocking and then eventually freezes the display and I have to 
>>> use power reset to recover my machine.   I discovered I am able to 
>>> view the programs using Open GL High Quality.   I'm not happy about 
>>> the higher CPU, but at least I can watch my programs.   However, two 
>>> other bad symptoms manifest.
>>>
>>> After the change, the timing information of the recordings is off.  
>>>  A 60 minute recording, when paused will report as 75 minutes.
>>>
>>> I suspect this is related to the third symptom which is that skip 
>>> forward or back doesn't work properly.  The first skip forward will 
>>> actually jump backward some random offset (usually 3 or 4 minutes) 
>>> and then progress forward from there with repeated commands.   A skip 
>>> backward does the same thing (first skip offset backwards 3 to 4 
>>> minutes).
>>>
>>> Note: I don't run any transcoding jobs on my recordings.   I've 
>>> upgraded to Ubuntu 20.04.3 with latest mythtv patches 
>>> (31.0+fixes.202111081900.25f1bb1d12~ubuntu20.04.1).
>>>
>>> Any suggestions?
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users at mythtv.org <mailto:mythtv-users at mythtv.org>
>>> http://lists.mythtv.org/mailman/listinfo/mythtv-users 
>>> <http://email.mg.glenb.net/c/eJwtjcsOgyAURL9GdyWIXNEFi276H5cLKAkPg9TEv69tmpnVOZOM1eTRguyDnpSVhiQZYRZLdjFKCFQG5js0-GkQRFyNnBEmFzvJ1-iyYdm1ftMGOHlvAUAoOUrLAecB50V4A4DC9lFvre3d-OzE624MRztYutrWTlbqeqOEISbMfxmyL1_4Wzzeh6tHX_UZMrm9lOru_wu3UhiV9AEsoj9v> 
>>>
>>> http://wiki.mythtv.org/Mailing_List_etiquette 
>>> <http://email.mg.glenb.net/c/eJwNjTESgyAQAF-jJXOCiBQUaVIlb3DgOIWJijEXM_4-zm61zUaHo4-6rbPrTGwDthhksBGjDUZKb4LuL7AZu0YiglEg0C80Vy1MM61BrMR1ckoZHS1E7IC0NAAWFKAk1ZMGHUM9u8S8VepWyfvlL7-yWE5OfIiyT1d5-jzndRoe-cMDcX5_iZnq3R15RdpK2el6nj6VIrAsfxpTOsU> 
>>>
>>> MythTV Forums: https://forum.mythtv.org 
>>> <http://email.mg.glenb.net/c/eJwNzDsOwyAQANHTmBKZ3wIFRZrcAxYwlow3IsSSbx9rXj05YI3ZaLYHsFkn1Jhk8hmzT1bKaJNxTygqCIm4WrVyjL0ci163o5yJn2WyFpwpWoD31SldAYyuaCEDCid9xajYEdqcn--iXot8PyqNX-f9nm1enMbGRrj2E8uHaJRnfsdGxJH6H1PbMnk> 
>>>
>>
>> i would check a few things to experiment. i assume the capture (.ts 
>> file in myth) is mpeg2 and ac3 audio .. right ?
>>
>> first on a completed recording see if just changing the container does 
>> anything. first move the finished file to a temp file: mv 
>> (mythrecname).ts temp.ts  then run: ffmpeg -i temp.ts -vcodec copy 
>> -acodec copy (mythrecname).ts after that check in the frontend and see 
>> if you have the same issues.
>>
>> if you still have those issues then consider just running a transcode 
>> job with ffmpeg when the recording completes and transcode the video 
>> to libx264..you could do it as a user job script and just filter for 
>> the offending channel. but first test it with
>>
>> run: mv (mythrecname).ts temp.ts then run: ffmpeg -i temp.ts vcodec 
>> libx264 -crf 24 -tune film -acodec copy (mythrecname).ts
>>
>> you would probably want to customize the ffmpeg libx264 options for 
>> deinterlace if you need etc... but it should play ok in the frontend.
> 
> Plays fine for me with software decoding on a 2.8 GHz core2duo machine. 
> But shock horror it's mpeg2video 1920x1080i @ 29.97 fps and the cpu load 
> is close to 2 x 100%
> 
> HTH
> 
> John P
> 

But I usually run project-X on my mpeg recordings, and it's not happy 
with this one.   I'll try something else.

{{{
  Duration: 00:06:45.25, start: 66178.166733, bitrate: 7671 kb/s
     Stream #0:0[0x760]: Video: mpeg2video (Main), yuv420p(tv, top 
first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 
59.94 tbc
     Side data:
       cpb: bitrate max/min/avg: 18824400/0/0 buffer size: 9764864 
vbv_delay: N/A
     Stream #0:1[0x761](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 
5.1(side), fltp, 384 kb/s
     Stream #0:2[0x762](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 
stereo, fltp, 128 kb/s

35 %!> dropping GOP# 155 @ orig.PTS 05:09:49.783 (1673080553), errorcode: 24
!> Pics exp/cnt 5/8, inGOP PTS diff. 0ms, new Timecode 00:01:50.610
!> dropping GOP# 156 @ orig.PTS 05:09:49.950 (1673095568), errorcode: 24
!> Pics exp/cnt 25/48, inGOP PTS diff. 16ms, new Timecode 00:01:50.610
!> dropping GOP# 157 @ orig.PTS 05:09:50.784 (1673170643), errorcode: 24
!> Pics exp/cnt 5/9, inGOP PTS diff. 0ms, new Timecode 00:01:50.610
!> dropping GOP# 158 @ orig.PTS 05:09:50.951 (1673185658), errorcode: 24
!> Pics exp/cnt 30/57, inGOP PTS diff. 0ms, new Timecode 00:01:50.610
!> dropping GOP# 159 @ orig.PTS 05:09:51.952 (1673275748), errorcode: 24
!> Pics exp/cnt 27/52, inGOP PTS diff. 16ms, new Timecode 00:01:50.610
36 %!> dropping GOP# 160 @ orig.PTS 05:09:52.853 (1673356829), errorcode: 24
!> Pics exp/cnt 18/34, inGOP PTS diff. 0ms, new Timecode 00:01:50.610
!> dropping GOP# 161 @ orig.PTS 05:09:53.454 (1673410883), errorcode: 24
!> Pics exp/cnt 4/7, inGOP PTS diff. 16ms, new Timecode 00:01:50.610
!> dropping GOP# 162 @ orig.PTS 05:09:53.587 (1673422895), errorcode: 24
!> Pics exp/cnt 25/49, inGOP PTS diff. 16ms, new Timecode 00:01:50.610
!> dropping GOP# 163 @ orig.PTS 05:09:54.421 (1673497970), errorcode: 24
!> Pics exp/cnt 25/49, inGOP PTS diff. 16ms, new Timecode 00:01:50.610
!> dropping GOP# 164 @ orig.PTS 05:09:55.256 (1673573045), errorcode: 24
!> Pics exp/cnt 30/60, inGOP PTS diff. 16ms, new Timecode 00:01:50.610
}}}}