Mailing List Archive: FFmpeg

FFmpeg

Feb 7, 2022, 9:02 AM

Post #1 of 5 (521 views)

Hi Scott

Thank you for all the hard work you are putting into MythTV.

You have a pull request in MythTV/mythtv for ffmpeg cleanup, and also
one in mythTV/FFmpeg for reversions.

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.

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.

This process necessarily loses all changes that have been committed to
MythTV/mythtv/external/FFmpeg.

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?

Do you recommend applying your pull requests before starting the merge,
rebase or cherry-pick of FFmpeg master into our FFmpeg?

Do you recommend a different process for incorporating FFmpeg 5.0?

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: FFmpeg [ In reply to ]

scott.the.elm at gmail

Feb 7, 2022, 10:53 AM

Post #2 of 5 (521 views)

Permalink

On 2/7/22 12:02, Peter Bennett wrote:
> You have a pull request in MythTV/mythtv for ffmpeg cleanup, and also
> one in mythTV/FFmpeg for reversions.
>
> 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.
>
> 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.
>
> This process necessarily loses all changes that have been committed to
> MythTV/mythtv/external/FFmpeg.
>
> 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?

All the changes to external/FFmpeg in
https://github.com/MythTV/mythtv/pull/416 are also in
https://github.com/MythTV/FFmpeg/pull/1 the reversions PR.

git diff reversions rebase/4.4m3
The only differences are from the extra two upstream commits that I
branched after.

>
> Do you recommend applying your pull requests before starting the
> merge, rebase or cherry-pick of FFmpeg master into our FFmpeg?

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.

Then I'll rebase onto FFmpeg's release/5.0.

I am also working on harmonizing mpegts-mythtv.(h|c) with mpegts.(h|c).
See https://github.com/ulmus-scott/FFmpeg/commits/harmonize .

git diff --no-index --color-moved libavformat/mpegts.c
libavformat/mpegts-mythtv.c

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.

Regards,
Scott

Re: FFmpeg cleanup [ In reply to ]

pb.mythtv at gmail

Feb 9, 2022, 11:42 AM

Post #3 of 5 (516 views)

Permalink

On 2/7/22 1:53 PM, Scott Theisen wrote:
> On 2/7/22 12:02, Peter Bennett wrote:
>> You have a pull request in MythTV/mythtv for ffmpeg cleanup, and also
>> one in mythTV/FFmpeg for reversions.
>>
>> 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.
>>
>> 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.
>>
>> This process necessarily loses all changes that have been committed
>> to MythTV/mythtv/external/FFmpeg.
>>
>> 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?
>
> All the changes to external/FFmpeg in
> https://github.com/MythTV/mythtv/pull/416 are also in
> https://github.com/MythTV/FFmpeg/pull/1 the reversions PR.
>
> git diff reversions rebase/4.4m3
> The only differences are from the extra two upstream commits that I
> branched after.
>
>>
>> Do you recommend applying your pull requests before starting the
>> merge, rebase or cherry-pick of FFmpeg master into our FFmpeg?
>
> 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.
>
> Then I'll rebase onto FFmpeg's release/5.0.
>
> I am also working on harmonizing mpegts-mythtv.(h|c) with
> mpegts.(h|c). See
> https://github.com/ulmus-scott/FFmpeg/commits/harmonize .
>
> git diff --no-index --color-moved libavformat/mpegts.c
> libavformat/mpegts-mythtv.c
>
> 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.
>
> Regards,
> Scott
>
>
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.

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.

I prefer not to squash commits, so that they can be bisected and bad
commits can be reverted.

Does this sound OK to you?

Peter

Re: FFmpeg cleanup [ In reply to ]

scott.the.elm at gmail

Feb 9, 2022, 1:44 PM

Post #4 of 5 (515 views)

Permalink

On 2/9/22 14:42, Peter Bennett wrote:
>
> 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.
>

The reason I have the FFmpeg changes there as well, is to enable
bisecting them if necessary with MythTV.

> 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.
>

My understanding of the git workflow with a fork is that you *don't*
want to work on the master branch. Instead you work on a different
branch (e.g. mythtv-on-master) so you can trivially git pull master.

> I prefer not to squash commits, so that they can be bisected and bad
> commits can be reverted.
>

My idea was since I have already rebased MythTV's customizations and
have now reverted a number of them, it doesn't make sense to keep that
history in the mythtv/FFmpeg repository. (It would still be in the
mythtv/mythtv repository.)

It seems we each want equivalent branches with different histories:

* mythtv-master: includes the reversion commits, which are then buried
under upstream FFmpeg commits, for ease of bisection.
* mythtv-on-master: mythtv customizations rebased on top of FFmpeg
master periodically, so we can see what the customizations are and
to enable upstreaming.

Re-targeting https://github.com/MythTV/FFmpeg/pull/1 onto
MythTV/FFmpeg/master doesn't look too difficult.

-Scott

Re: FFmpeg 5.0 [ In reply to ]

scott.the.elm at gmail

Feb 12, 2022, 1:55 PM

Post #5 of 5 (507 views)

Permalink

Peter,

The compilation errors in mpegsts-mythtv.c I mentioned concerning my
rebase of MythTV's changes onto FFmpeg/release/5.0 are from the
following commits:

avformat: move AVStream.{parser,need_parsing} to AVStreamInternal ·
FFmpeg/FFmpeg@b9c5fdf
https://github.com/FFmpeg/FFmpeg/commit/b9c5fdf6027010d15ee90a43aa023e45a5189097

avformat: Avoid allocation for AVStreamInternal · FFmpeg/FFmpeg@40bdd8c
https://github.com/FFmpeg/FFmpeg/commit/40bdd8cc05d9c98a18cf2b1c2a00c8a5a7b38113

avformat/avio: Move internal AVIOContext fields to avio_internal.h ·
FFmpeg/FFmpeg@45bfe8b
https://github.com/FFmpeg/FFmpeg/commit/45bfe8b838275235412777dd430206d9a24eb3ee

The final error is from the removal of av_free_packet().

Regards,

Scott