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