<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2/7/22 1:53 PM, Scott Theisen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:310ca351-d896-37d1-9a5c-9cb510b94a03@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 2/7/22 12:02, Peter Bennett wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3a07e4b2-8177-76f1-aede-268c6c407736@gmail.com">You
have a pull request in MythTV/mythtv for ffmpeg cleanup, and
also one in mythTV/FFmpeg for reversions. <br>
<br>
I would also like to start merging the latest FFmpeg master in
preparation for FFmpeg 5.0. My process is to merge from
FFmpeg/FFmpeg master into MythTV/FFmpeg master up to the point
where FFmpeg creates release/5.0, then create release/5.0 in
MythTV/FFmpeg. Once everything is successfully merged, then copy
the FFmpeg contents into MythTV, ffmpeg-resync branch.
ffmpeg-resync branch will be deleted and recreated from master.
<br>
<br>
In order to make bisecting FFmpeg changes easier I would like to
try multiple cherry-pick or rebase instead of merge into our
FFmpeg so that there is a single line history of commits. <br>
<br>
This process necessarily loses all changes that have been
committed to MythTV/mythtv/external/FFmpeg. <br>
<br>
The ffmpeg cleanup pull request contains changes to
MythTV/mythtv/external/FFmpeg which will be lost. Are all of
those changes contained in the reversions pull request? <br>
</blockquote>
<br>
All the changes to external/FFmpeg in <a
class="moz-txt-link-freetext"
href="https://github.com/MythTV/mythtv/pull/416"
moz-do-not-send="true">https://github.com/MythTV/mythtv/pull/416</a>
are also in <a class="moz-txt-link-freetext"
href="https://github.com/MythTV/FFmpeg/pull/1"
moz-do-not-send="true">https://github.com/MythTV/FFmpeg/pull/1</a>
the reversions PR.<br>
<br>
git diff reversions rebase/4.4m3<br>
The only differences are from the extra two upstream commits that
I branched after.<br>
<br>
<blockquote type="cite"
cite="mid:3a07e4b2-8177-76f1-aede-268c6c407736@gmail.com"> <br>
Do you recommend applying your pull requests before starting the
merge, rebase or cherry-pick of FFmpeg master into our FFmpeg? <br>
</blockquote>
<br>
The FFmpeg PR is equivalent to rebase/4.4m3 so I would recommend
applying the MythTV PR first, so I can then rebase and squash
those commits back onto release/4.4.<br>
<br>
Then I'll rebase onto FFmpeg's release/5.0.<br>
<br>
I am also working on harmonizing mpegts-mythtv.(h|c) with
mpegts.(h|c). See <a class="moz-txt-link-freetext"
href="https://github.com/ulmus-scott/FFmpeg/commits/harmonize"
moz-do-not-send="true">https://github.com/ulmus-scott/FFmpeg/commits/harmonize</a>
.<br>
<br>
git diff --no-index --color-moved libavformat/mpegts.c
libavformat/mpegts-mythtv.c<br>
<br>
I decided since most of the functions using the old packet API
were unmodified by MythTV, it would be easier to just copy the
versions from FFmpeg 4.4. Unfortunately, most of the MythTV
modifications are buried under 17 years of updates.<br>
<br>
Regards,<br>
Scott<br>
<style type="text/css">p { line-height: 115%; margin-bottom: 0.1in; background: transparent }a:visited { color: #800000; so-language: zxx; text-decoration: underline }a:link { color: #000080; so-language: zxx; text-decoration: underline }</style><br>
<br>
</blockquote>
<p>The pull request for ffmpeg cleanup has 73 commits. I will start
going through them starting at the first and cherry-picking them
into MythTV master. I will exclude any changes to the ffmpeg
directory, as those will be made in the MythTV/FFmpeg repository.
If any of the changes to MythTV are dependent on corresponding
FFmpeg changes I will leave them until later.<br>
</p>
<p>The MythTV/FFmpeg repository changes will need to be made against
MythTV/FFmpeg/master, not against 4.4 or 5.0, so that subsequent
changes from FFmpeg/FFmpeg/master can be incorporated over them
into MythTV/FFmpeg/master. I plan to cherry-pick the
FFmpeg/FFmpeg/master changes into MythTV/FFmpeg/master so that
there is a linear history that can be bisected if necessary.<br>
</p>
<p>I prefer not to squash commits, so that they can be bisected and
bad commits can be reverted.</p>
<p>Does this sound OK to you?<br>
</p>
<p>Peter<br>
</p>
</body>
</html>