[mythtv] Decision on FFmpeg repository

[David Engel]

On Thu, May 17, 2018 at 07:23:06PM -0400, David Hampton wrote:
> 
> 
> On May 16, 2018 10:24:09 PM EDT, Mark Spieth <mark at digivation.com.au> wrote:
> >
> >On 17/05/18 08:52, David Engel wrote:
> >> On Thu, May 17, 2018 at 08:16:26AM +1000, Mark Spieth wrote:
> >>> On 5/17/2018 2:45 AM, Peter Bennett wrote:
> >>>> I would like to get a decision on what to do about a couple of
> >FFmpeg
> >>>> questions:
> >>>>
> >>>> 1. Use FFmpeg master or release branch? My recommendation is to use
> >>>> master.
> >>>> - the FFmpeg website recommends using master for those who are
> >compiling
> >>>> FFmpeg themselves. It states that the release branches are for
> >those who
> >>>> rely on downloaded prebuilt packages
> >>>> (https://ffmpeg.org/download.html#repositories).
> >>>> - Only master has the recent mediacodec changes which I need for
> >android.
> >>>> - If we sync to master, we can use a better approach for the
> >repository
> >>>> (question 2 below).
> >>>>
> >>>> 2. What method should we use for storing and syncing with FFmpeg
> >source?
> >>>> Options are:
> >>>> a. Reapply patches to the source from FFmpeg, resolve conflicts,
> >and
> >>>> copy the source over what we have in MythTV (current process). This
> >can
> >>>> be very time-consuming.
> >>>>
> >>>> b. Use a subtree in the MythTV repository.
> >>>> - This will not work if we use a release branch (question 1).
> >>>> - When resyncing, we can do a git merge of the subtree from FFmpeg.
> >>>> - We can cherry-pick changes needed without resyncing everything.
> >>>> - We can sync to any required commit, we don't need to go all the
> >way to
> >>>> the latest commit.
> >>>> - git log shows FFmpeg commits intermingled with MythTV. You can
> >use
> >>>> "git log -- mythtv" which eliminates those.
> >>>> - This imports some 90,000 extra commits from FFmpeg.
> >>>>
> >>>> You can see an example of the subtree in use at
> >>>> https://github.com/bennettpeter/mythtv/tree/ffmpeg-subtree or clone
> >that
> >>>> repo and look at the ffmpeg-subtree branch.
> >>>>
> >>>> c. Keep our own customized FFmpeg repository with patches applied.
> >>>> - This will not work if we use a release branch (question 1).
> >>>> - When resyncing, do a git pull or merge on the private FFmpeg
> >>>> repository. Then copy the entire source over the MythTV FFmpeg
> >source.
> >>>> - We can cherry-pick changes needed without resyncing everything.
> >>>> - We can sync to any required commit, we don't need to go all the
> >way to
> >>>> the latest commit.
> >>>> - git log in MythTV does not show all the FFmpeg commits.
> >>>> - git log in the private FFmpeg repository shows records of our
> >patches
> >>>> along with all the FFmpeg commits.
> >>>> - We can perform periodic pulls into the private FFmpeg repository
> >>>> without affecting MythTV. This will make the eventual copying into
> >>>> MythTV quicker and easier.
> >>>> - Any FFmpeg patches that we apply between copying into MythTV must
> >be
> >>>> applied in both MythTV and FFmpeg repositories, or apply them in
> >the
> >>>> private FFmpeg repository and then wait for the next copy into
> >MythTV.
> >>>>
> >>>> You can see an example of FFmpeg with patches applied at
> >>>> https://github.com/bennettpeter/FFmpeg
> >>> I too am not comfortable using master but your justification is
> >sound.
> >>> Is there a prerelease with mediacodec added? probably not.
> >>> You could start with master until mediacodec is released.
> >>>
> >>> Im not sure if you tried this but you could use 2b in a
> >ffmpeg-tracking
> >>> branch and then merge with squash to master, where the patches are.
> >>> Im not sure how well this would work compared with tracking ffmpeg
> >in master
> >>> though wrt applying patches on top of ffmpeg compared with master
> >only, but
> >>> it would remove the log issue.
> >>>
> >>> Perhaps process of merge master to tracking, update subtree, fix
> >conflicts
> >>> in tracking, merge with squash back to master, fixup any issues in
> >master.
> >> I think that would have the same problem Peter ran into when trying
> >2b
> >> without squash.  That is without the intermediate commits, git marked
> >> everything as conflicting on subsequent updates because it didn't
> >know
> >> what to base them on.
> >>
> >but you do get the full history in the ffmpeg-tracking branch, just not
> >
> >master.
> >BOBW
> 
> I'm not particularly concerned with branch vs master, or whether it's a submodule/subtree/subrepo. Whatever it is,  I'd rather not have the git logs polluted with 90,000 extra entries. That's three times as many entries as exist for our main branch. 

I wonder if --no-ff would help when merging ffmpeg's changes into our
master branch.  I know there are cases, like this maybe, where git
puts a single, "merge" commit on the main branch.  When that happens,
I believe git requires extra log options to see all of the individual
commits that were merged.

David
-- 
David Engel
david at istwok.net