[mythtv] Call for testing branch devel/ffmpeg-resync (mpegts-harmonize)

[John Pilkington]

On 27/07/2022 02:54, Scott Theisen wrote:
> On 7/26/22 18:41, John Pilkington wrote:
>> On 26/07/2022 20:09, Scott Theisen wrote:
>>> On 7/26/22 14:10, Scott Theisen wrote:
>>>> Initial impression: probable double free 
>>>
>>> I would like mythcommflag logs with `-v libav:debug` from both master 
>>> and ffmpeg-resync.
>>>
>>> It appears that since add_section_stream() reuses the SectionContext 
>>> if it already exists, this leads to two DSMCC streams with the same 
>>> value of the pointer priv_data which then is double freed since it is 
>>> freed with each stream.
>>>
>>> This should fix the double free, but I need you to test if the 
>>> DSMCC/MHEG streams still work correctly since I can't:
>>> ```
>>> diff --git a/mythtv/external/FFmpeg/libavformat/mpegts-mythtv.c 
>>> b/mythtv/external/FFmpeg/libavformat/mpegts-mythtv.c
>>> index 4a74c5c3ac..90229cf6ae 100644
>>> --- a/mythtv/external/FFmpeg/libavformat/mpegts-mythtv.c
>>> +++ b/mythtv/external/FFmpeg/libavformat/mpegts-mythtv.c
>>> @@ -2494,12 +2494,17 @@ static SectionContext 
>>> *add_section_stream(MpegTSContext *ts, int pid, int stream
>>>       MpegTSFilter *tss = ts->pids[pid];
>>>       SectionContext *sect = 0;
>>>       if (tss) { /* filter already exists */
>>> +#if 0
>>> +/*
>>> +returning the preexisting SectionContext causes it to be double 
>>> freed when its
>>> +owning AVStream is freed.  (It gets freed via AVStream.priv_data.)
>>> +*/
>>>           if (tss->type == MPEGTS_SECTION)
>>>               sect = (SectionContext*) tss->u.section_filter.opaque;
>>>
>>>           if (sect && (sect->stream_type == stream_type))
>>>               return sect; /* if it's the same stream type, just 
>>> return ok */
>>> -
>>> +#endif
>>>           /* otherwise, kill it, and start a new stream */
>>>           mpegts_close_filter(ts, tss);
>>>       }
>>>
>>> ```
>>>
>>> Regards,
>>>
>>> Scott
>>
>> Attachment is from the unpatched build of ffmpeg-resync.  Will try the 
>> rest tomorrow.
> 
>  From that log I noticed a minor bug in the codec descriptors location 
> and I have added a new commit to my pull requests.  (This only effects 
> the logging.  Instead of `unknown_codec` it should say `dsmcc_b` for 
> codec 0x17813, AV_CODEC_ID_DSMCC_B.)
> 
> I also noticed that it appears to create 5 streams for each of the two 
> PIDs for DSMCC streams, but I await the log from master for comparison.
> 
> Regards,
> 
> Scott

Attachment using master from the same short recording of BBC ONE evening 
news.

mythcommflag --rebuild --file <filename> -v libav:debug --logpath 
~/SGs/Recs/

Quitting that recording in ffmpeg-resync causes a segfault.  That 
doesn't happen with eg SkyArts, which doesn't have the extra streams.

TBH my first action is usually to strip off non-AV streams.  That has 
seemed a historically effective way of avoiding problems.  I have rarely 
used MythTV with what is described in the UK as Interactive TV (although 
I use the Normal recording profile) so am probably not a good judge of 
how DSMCC/MHEG is handled.  I did come across this document which might 
be of interest - or just TL;DR

https://www.freeview.co.uk/sites/default/files/2020-08/freeview-play-technical-specification-2021.pdf

John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mythcommflag.20220727091713.33345.tar.gz
Type: application/gzip
Size: 3704 bytes
Desc: not available
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20220727/930cc35d/attachment.gz>