[mythtv] Harmonizing mpegts-mythtv.(c|h) with FFmpeg's mpegts.(c|h)

[Scott Theisen]

On 2/17/22 10:01, John Pilkington wrote:
> I'm not a MythTV developer or a serious coder;  I've just been using 
> and taking an interest in it for many years.  But IIRC the project 
> started using its own 'fork' of ffmpeg because unexpected changes made 
> by the ffmpeg team could immediately affect MythTV users, whose 
> maintainers would then have to try to pick up the pieces.

Maintaining downstream changes is also a maintenance burden.

>
> Doesn't this still seem likely if 'harmonisation' goes too far ? 

This is why I reordered the commits, because some proved problematic.

On 2/17/22 14:11, Klaas de Waal wrote:
> The basic reason why there is a MythTV version of the ffmpeg demuxer 
> is that the ffmpeg demuxer does not handle changes in streams very 
> well. E.g. changes in subtitling, changes in video format etc. So the 
> ffmpeg demuxer works OK for playing a stream that does not change. In 
> general, MythTV recordings extend beyond single programs and can also 
> include commercials, other breaks etc. Going from one program to 
> another or from a program to a commercial to another program is where 
> the pain is.  My latest changes to the MythTV demuxer have been done 
> to support the broadcast streams from YLE which happen to have lots of 
> changes. 

That is why I was testing with those samples.  It appeared to play fine 
without exporting the PMT for MythTV, but I'll have to look at it again.

> And the remark of JohnP is also valid, for example during the last 
> update of ffmpeg in december or so there was suddenly the "blocking at 
> skip" problem which I bisected back to a specific ffmpeg commit. This 
> commit Peter then excluded from the MythTV version of ffmpeg.

Klaas, you may want to ping that bug https://trac.ffmpeg.org/ticket/9532 
since your upload link didn't initially work.  Although, it might be 
better to test with FFmpeg 5.0 first.

> If we want to use the ffmpeg libraries from the system then we must 
> have a way to do runtime patching the ffmpeg shared libraries. These 
> things can be done using what is called intercepts and library 
> pre-loads but this must then be done for every ffmpeg version on every 
> supported system. And this is the kind of software that should be used 
> for testing and not for products.

I agree that doesn't seem feasible.

> So I think that we will have to stick to our own version of ffmpeg.
>

For now, yes.  I still think being able to use the system's version of 
ffmpeg is a good goal to work towards.

Scott