[mythtv] Decision on FFmpeg repository

[Mark Spieth]

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

Mark