[mythtv] master dcb64 of 15 Aug: ffprobe/mythffprobe discrepancy

[John Pilkington]

On 30/08/2022 20:11, Scott Theisen wrote:
> 
> 
> On 8/24/22 05:20, John Pilkington wrote:
>> On 23/08/2022 21:27, John Pilkington wrote:
>>> Hi:  I have an h264-based video for which stream analyses by the 
>>> F35-system ffprobe and ffmpeg report initial errors but then give ok 
>>> results, while mythffprobe and mythffmpeg both crash.
>>>
>>> I had mistimed my recording, and downloaded a replacement from the 
>>> BBC via get_iplayer, which would normally transcode to mpeg4, but ran 
>>> out of disk space, leaving the raw download instead.  So it isn't a 
>>> standard MythTV format; but playback in the frontend and other 
>>> players seemed generally ok.  I have since used the system ffmpeg to 
>>> convert it into my normal format.
>>>
>>> Here are links to two 20 MB dd-clips.
>>>
>>> dd bs=1M skip=20 count=20 if=<infile> of=<outfile>
>>>
>>> They aren't packet-aligned or exactly equivalent.
>>>
>>> Bad
>>> https://drive.google.com/file/d/1EidSzuf8KbMWQcPKfW3XEWCdFvIprGYc/view?usp=sharing 
>>>
>>>
>>> Good
>>> https://drive.google.com/file/d/1z3UxPNY162JTMMDZ1uDC_J5wMS7nKE8P/view?usp=sharing 
>>>
>>>
>> I've tried the mythffprobe from fixes/32 on both clips.  After the 
>> complaints, here are the essentials.  I don't know if the differing 
>> stream labels might have anything to do with the problem in master.
>>
>> Input #0, mpegts, from 'prom_iplay_20_20.ts':
>>   Duration: 00:00:30.62, start: 46.760000, bitrate: 5479 kb/s
>>   Stream #0:0[0x22](eng): Audio: aac (LC), 48000 Hz, stereo, fltp, 132 
>> kb/s
>>   Stream #0:1[0x21]: Video: h264 (High), yuv420p(tv, bt709, 
>> progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 
>> 100 tbc
>> ==============
>>
>> Input #0, mpegts, from 'prom_ok_20_20.ts':
>>   Duration: 00:00:31.32, start: 37.282667, bitrate: 5357 kb/s
>>   Stream #0:0[0x100]: Video: h264 (High), yuv420p(tv, bt709, 
>> progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 
>> 100 tbc
>>   Stream #0:1[0x101](eng): Audio: aac (LC), 48000 Hz, stereo, fltp, 
>> 130 kb/s
>> =============
> 
> The problem is one of my harmonize commits/the customization to 
> mpegts-mythtv.c.
> 
> from gdb:
> ```
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff79fa1d9 in mpegts_read_header (s=0x5555555b79c0) at 
> libavformat/mpegts-mythtv.c:3732
> 3732                if (ts->pids[ts->req_sid] &&
> (gdb) print ts->req_sid
> $1 = 16727
> ```
> 
> But MpegTSContext::pids[] is only 8192 elements long.  See attached 
> patch for fix, if interested.  I'll open a pull request to master, and 
> to our FFmpeg master and 5.1 after testing removing the customization 
> entirely.
> 
> The stream id being different is not a problem, since FFmpeg's ffprobe 
> also shows that.  Did you remux the file?  That could change the stream 
> ids.
> 
> Regards,
> 
> Scott Theisen

Yes, it was remuxed.  IIRC the command (before the dd cutting) was

ionice -c3 ffmpeg -hide_banner -ignore_unknown  -fflags +genpts
-ss -0.0200 -t 36000.0400    -i infile.ts
-vcodec copy -acodec copy -avoid_negative_ts make_zero
-f mpegts  outfile.ts

Thanks for looking at this,

John