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

[Scott Theisen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libavformat-mpegts-mythtv.c-fix-segmentation-fault-f.patch
Type: text/x-patch
Size: 2769 bytes
Desc: not available
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20220830/c2625bf7/attachment.bin>