Mailing List Archive

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
=============

> John P

_______________________________________________
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

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

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

_______________________________________________
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