[mythtv] ffmpeg pull requests
scott.the.elm at gmail.com
Wed Jun 1 02:29:16 UTC 2022
On 5/31/22 21:22, Scott Theisen wrote:
> You already merged all of the changes to FFmpeg from
> https://github.com/MythTV/mythtv/pull/416 (except
> 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
>> 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.
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.
More information about the mythtv-dev