[mythtv] Decision on FFmpeg repository

[David Engel]

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.

David
-- 
David Engel
david at istwok.net