[mythtv] ffmpeg pull requests

[Scott Theisen]

On 5/31/22 21:22, Scott Theisen wrote:
> Peter,
>
> You already merged all of the changes to FFmpeg from 
> https://github.com/MythTV/mythtv/pull/416 (except 
> https://github.com/MythTV/mythtv/pull/416/commits/5c6288f52f6c6b3e07992bae6c9ba80e051fbb78 
> and 
> https://github.com/MythTV/mythtv/pull/416/commits/a51d4e8b67cfa5dc54744c7339527c2c79d14455) 
> to https://github.com/MythTV/FFmpeg/commits/master back in February.
>
> However, I have slightly re-worked some of the changes to make them 
> more coherent and grouped together, instead of mixing it all together 
> as I went.  The end results should be the same, however.
>
> On 5/31/22 09:41, Peter Bennett wrote:
>> Please can you let me know which ffmpeg pull requests are ready to go. 
>
> https://github.com/MythTV/mythtv/pull/557 ByteReader (replace 
> avpriv_find_start_code) the change to FFmpeg is in a separate commit 
> and not strictly necessary for that PR (although it does silence many 
> warnings when compiling FFmpeg).  This PR needs to be merged before I 
> can submit my BitReader PR to replace the use of get_bits.h and 
> golomb.h in MythTV (shared context lines in MythTV).
>
> https://github.com/MythTV/mythtv/pull/565 lavc/utils-mythtv.c (MythTV 
> changes depend on the FFmpeg changes in order to work fully.)
>
> https://github.com/MythTV/mythtv/pull/566 libpostproc; solely changes 
> to FFmpeg, identical to what you already merged. Independent of all 
> other changes.
>
> https://github.com/MythTV/mythtv/pull/568 independent MythTV change 
> split from a commit that I have redone.
>
>> Code changes need to be applied to the MythTV/FFmpeg repository 
>> first, then we can copy the structure into MythTV/mythtv, 
>> ffgmpeg-resync branch. 
>
> An alternative would be to edit the patches generated by `git 
> format-patch` to remove the MythTV parts and fix the paths, `git am 
> *.patch` to apply them to ffmpeg/release/4.4 and then rebase onto 
> master.  (This is what I did to move the patches back and forth 
> between the two repositories).
>
>> we need to keep commits that affect ffmpeg separate from ones that 
>> affect the MythTV code.
>
> They are interdependent, so that is impossible.  Most FFmpeg changes 
> depend on MythTV changes, but some MythTV changes depend on FFmpeg 
> changes.
>
>>
>> Once they are done, we can attempt merging ffmpeg 5.
>>
>> Does this sound good to you? Do you have any recommendations for a 
>> better way to get everything merged with the least pain?. Having the 
>> MythTV/FFmpeg repository makes it easier to merge new versions, but 
>> does separate out the history and makes it more difficult to track 
>> down bugs, however I don't know of any better way.
>
> The cleanup changes depend on each other (both ways), so that history 
> needs to be in the MythTV repository.
>
> I want to merge the changes to MythTV first, because of their 
> interdependence, and to create a sensible history for bisection if 
> necessary.  Then, I can separate out the changes to FFmpeg as 
> described above (if necessary, although I know I made some different 
> changes); however, I'm not sure if you want to keep the ffmpeg/master 
> history that you already merged or create a new history that is one to 
> one with the MythTV repository.
>
> However, my mpegts-mythtv.c harmonization should, in my opinion, 
> appear in the MythTV repository as a single monolithic change because 
> I can't guarantee that it works at each commit.  It compiles at each 
> commit and works at the end, but I didn't test the intermediate 
> commits.  This should be separate from and before the merging of 
> FFmpeg 5.0.
>
> Regards,
>
> Scott

On second thought, I think the only MythTV changes that depend on FFmpeg 
changes are av_disposition (https://github.com/MythTV/mythtv/pull/575 ) 
and lavc/utils (https://github.com/MythTV/mythtv/pull/565 ), so other 
than those two the already merged in ffmpeg/master history will suffice.

I'll create PRs for just the changes to MythTV and a new PR to FFmpeg 
for the av_disposition change.

Regards,

Scott