[mythtv] Decision on FFmpeg repository

David Hampton mythtv at love2code.net
Thu May 17 23:23:06 UTC 2018



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. 

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20180517/8414b474/attachment.html>


More information about the mythtv-dev mailing list