On 6/19/20 6:59 AM, Mark Kendall wrote:
> Hi Peter
>
> I was previously tracking the state of the v4l2 changes against FFmpeg
> master - but haven't looked at it in probably 6 months?
>
> Would it work if I consolidated all of the v4l2 changes into 1 patch
> that applies to the latest FFmpeg? It should be fairly clean as most
> of the subsequent updates were just bringing the original patch in
> line with FFmpeg master. I may then look at submitting to FFmpeg
> (which is normally painful at the best of times!).
>
> So apply all of the other FFmpeg changes, apply single v4l2 patch and
> merge that in? Does that retain visibility/history etc?
>
> Thanks and regards
> Mark
>
> On Thu, 18 Jun 2020 at 20:13, Peter Bennett <pb.mythtv@gmail.com> wrote:
>> Hi Mark
>>
>> The ffmpeg sync methodology I am using makes the assumption that we make
>> very few changes to the ffmpeg code, and the major part is making sure
>> that past changes are kept in place. I would have liked to go back to
>> the unchanged ffmpeg code, but that is not possible without MythTV changes.
>>
>> We have a github MythTV repository for FFmpeg (MythTV/FFmpeg.git), which
>> is our version of FFmpeg with past changes. The process I use for
>> merging new versions is described in the file
>> MythTV/mythtv/external/FFmpeg/README.sync and MythTV/FFMpeg/README.sync
>>
>> Since the last sync the following commits have been made against the
>> FFmpeg files in MythTV (see below). The process requires these changes
>> to be first made in the MythTV/FFmpeg repository, master branch. The
>> first commit (cc7572f9b2) is very large and fails to apply to our FFmpeg
>> master. I looked at the code but it is not an easy thing to fix. It
>> looks like many new functions were added and existing functions may also
>> have been moved around. Other commits also look troubling.
>>
>> * 3e1af48033 2020/06/16 David Hampton : Pass the correct stack-alignment
>> flag to the clang compiler.
>> * 498502a5eb 2020/06/15 David Hampton : tidy: Quiet a couple of warnings
>> in FFmpeg.
>> * cc80f6788b 2020/02/11 David Hampton : Merge branch 'master' into
>> branch 'cleanups'.
>> |\
>> | * 165fc1ca4c 2020/02/06 Mark Kendall : V4l2: Update FFmpeg v4l2 to
>> latest master
>> * | 459fccb5aa 2020/02/11 David Hampton : tidy: Remove
>> __STDC_CONSTANT_MACROS and __STDC_LIMIT_MACROS
>> |/
>> * 669955c6cb 2020/01/30 Mark Kendall : FFmpeg: Patch v4l2_buffers to
>> pass through interlaced fields
>> * 2c6f8618e0 2020/01/22 Mark Kendall : utils-mythtv: Add a couple of
>> missing codecs
>> * a0fbaa1736 2019/12/11 David Hampton : FFmpeg: Remove obsolete
>> 'register' keyword.
>> * 90f41b3860 2019/12/09 Mark Kendall : FFmpeg: Squash unused parameter
>> warning
>> * 253d4df440 2019/11/30 Mark Kendall : FFmpeg: Update v4l2_m2m code to
>> latest FFmpeg master
>> * fdc0645aba 2019/11/20 Mark Kendall : V4L2 Codecs: Fix lockup when
>> seeking
>> * 785c821f69 2019/11/14 Mark Kendall : FFmpeg: Further updates to v4l2
>> code
>> * 8fdb15fc96 2019/11/13 Mark Kendall : FFmpeg: Update v4l2 codecs code
>> to FFmpeg master
>> * bc905cfa79 2019/11/12 Mark Kendall : configure: Try to fix libdrm
>> again...
>> * 78dff9718b 2019/11/12 Mark Kendall : configure: Cleanup setup for
>> drm, opengl, egl and v4l2
>> * 783dc8ba7d 2019/11/10 Mark Kendall : v4l2: Workaround missing DRM define
>> * cc7572f9b2 2019/11/09 Mark Kendall : FFmpeg: Patch FFmpeg for V4L2
>> codecs DRM PRIME support
>>
>> This is the process I use for getting the patch into MythTV/FFmpeg:
>>
>> in MythTV/mythtv repo
>> git show cc7572f9b2 > ~/patch/cc7572f9b2.patch
>> edit the patch file to remove non-ffmpeg files
>> in MythTV/FFmpeg repo, master branch
>> git apply -p4 --reject ~/patch/cc7572f9b2.patch
>>
>> Attached is the patch file and error output. The "git apply" also
>> creates "rej" files with rejected parts of the patch for each file patched..
>>
>> I don't know what these changes do, and whether they may be supplanted
>> by later changes in FFmpeg.
>>
>> Normally, the changes I have to deal with consist of a few lines changed
>> and if there is a conflict it is easy to resolve.
>>
>> What do you suggest? The The changes need to be made into the
>> MythTV/FFmpeg master branch and then cherry-picked into the new 4.3
>> branch after the main FFmpeg merge.
>>
>> I am afraid that even if we get all these changes made in MythTV/FFmpeg
>> master, that the merge of FFmpeg/FFmpeg that I must do after that will
>> fail because of the large number of changes.
>>
>> Where there are new functions to be added, can we add them to a separate
>> source file that is specific to MythTV? This would likely make things a
>> lot easier.
>>
>> Let me know what you want to do. At the moment I am stuck.
>>
>> Peter
>>
>>
>>
Hi Mark
It looks like all of most of your commits are related to v4l2.
David Hampton has a bunch of commits which seem to be mainly related to
compiler warnings.
I would like to propose this:
I can create a new branch for the ffmpeg-sync (devel/ffmpeg4.3). I will
update FFmpeg to v4.3 in that branch, with none of the commits to ffmpeg
since the last sync (2019/11/05). MythTV compile will likely fail, since
there are changes that depend on your v4l2 code.
Then you can re-apply your v4l2 changes. To avoid future problems, you
can make the changes in the MythTV/FFmpeg repository, master version and
cherry-pick them into the release/4.3 branch there, and apply them to
MythTV.
Is it possible to create separate new source files for the new
functions? I know there were several functions added in your changes,
and there should be no reason they cannot be in a separate file. That
would reduce the chance of conflicts in future, or at least make them
easier to resolve. If those are later included in the base code by the
ffmpeg team, we can then delete the separate source file.
I see one comment is "updating to latest ffmpeg master code". If you
need to do that, perhaps we should do a merge from ffmpeg master to get
the new code.
I can help with any of this. If you prefer you can add your changes to
the mythtv repository, then let me know and I will include them in
MythTV/FFmpeg right away, rather than waiting for the next sync.
To David:
I would like to recommend against making changes to ffmpeg code that are
solely to fix warnings or for cosmetic items. This can cause conflicts
when merging in new releases of ffmpeg. You can try submitting them to
the FFmpeg team for inclusion in a future release.
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
> Hi Peter
>
> I was previously tracking the state of the v4l2 changes against FFmpeg
> master - but haven't looked at it in probably 6 months?
>
> Would it work if I consolidated all of the v4l2 changes into 1 patch
> that applies to the latest FFmpeg? It should be fairly clean as most
> of the subsequent updates were just bringing the original patch in
> line with FFmpeg master. I may then look at submitting to FFmpeg
> (which is normally painful at the best of times!).
>
> So apply all of the other FFmpeg changes, apply single v4l2 patch and
> merge that in? Does that retain visibility/history etc?
>
> Thanks and regards
> Mark
>
> On Thu, 18 Jun 2020 at 20:13, Peter Bennett <pb.mythtv@gmail.com> wrote:
>> Hi Mark
>>
>> The ffmpeg sync methodology I am using makes the assumption that we make
>> very few changes to the ffmpeg code, and the major part is making sure
>> that past changes are kept in place. I would have liked to go back to
>> the unchanged ffmpeg code, but that is not possible without MythTV changes.
>>
>> We have a github MythTV repository for FFmpeg (MythTV/FFmpeg.git), which
>> is our version of FFmpeg with past changes. The process I use for
>> merging new versions is described in the file
>> MythTV/mythtv/external/FFmpeg/README.sync and MythTV/FFMpeg/README.sync
>>
>> Since the last sync the following commits have been made against the
>> FFmpeg files in MythTV (see below). The process requires these changes
>> to be first made in the MythTV/FFmpeg repository, master branch. The
>> first commit (cc7572f9b2) is very large and fails to apply to our FFmpeg
>> master. I looked at the code but it is not an easy thing to fix. It
>> looks like many new functions were added and existing functions may also
>> have been moved around. Other commits also look troubling.
>>
>> * 3e1af48033 2020/06/16 David Hampton : Pass the correct stack-alignment
>> flag to the clang compiler.
>> * 498502a5eb 2020/06/15 David Hampton : tidy: Quiet a couple of warnings
>> in FFmpeg.
>> * cc80f6788b 2020/02/11 David Hampton : Merge branch 'master' into
>> branch 'cleanups'.
>> |\
>> | * 165fc1ca4c 2020/02/06 Mark Kendall : V4l2: Update FFmpeg v4l2 to
>> latest master
>> * | 459fccb5aa 2020/02/11 David Hampton : tidy: Remove
>> __STDC_CONSTANT_MACROS and __STDC_LIMIT_MACROS
>> |/
>> * 669955c6cb 2020/01/30 Mark Kendall : FFmpeg: Patch v4l2_buffers to
>> pass through interlaced fields
>> * 2c6f8618e0 2020/01/22 Mark Kendall : utils-mythtv: Add a couple of
>> missing codecs
>> * a0fbaa1736 2019/12/11 David Hampton : FFmpeg: Remove obsolete
>> 'register' keyword.
>> * 90f41b3860 2019/12/09 Mark Kendall : FFmpeg: Squash unused parameter
>> warning
>> * 253d4df440 2019/11/30 Mark Kendall : FFmpeg: Update v4l2_m2m code to
>> latest FFmpeg master
>> * fdc0645aba 2019/11/20 Mark Kendall : V4L2 Codecs: Fix lockup when
>> seeking
>> * 785c821f69 2019/11/14 Mark Kendall : FFmpeg: Further updates to v4l2
>> code
>> * 8fdb15fc96 2019/11/13 Mark Kendall : FFmpeg: Update v4l2 codecs code
>> to FFmpeg master
>> * bc905cfa79 2019/11/12 Mark Kendall : configure: Try to fix libdrm
>> again...
>> * 78dff9718b 2019/11/12 Mark Kendall : configure: Cleanup setup for
>> drm, opengl, egl and v4l2
>> * 783dc8ba7d 2019/11/10 Mark Kendall : v4l2: Workaround missing DRM define
>> * cc7572f9b2 2019/11/09 Mark Kendall : FFmpeg: Patch FFmpeg for V4L2
>> codecs DRM PRIME support
>>
>> This is the process I use for getting the patch into MythTV/FFmpeg:
>>
>> in MythTV/mythtv repo
>> git show cc7572f9b2 > ~/patch/cc7572f9b2.patch
>> edit the patch file to remove non-ffmpeg files
>> in MythTV/FFmpeg repo, master branch
>> git apply -p4 --reject ~/patch/cc7572f9b2.patch
>>
>> Attached is the patch file and error output. The "git apply" also
>> creates "rej" files with rejected parts of the patch for each file patched..
>>
>> I don't know what these changes do, and whether they may be supplanted
>> by later changes in FFmpeg.
>>
>> Normally, the changes I have to deal with consist of a few lines changed
>> and if there is a conflict it is easy to resolve.
>>
>> What do you suggest? The The changes need to be made into the
>> MythTV/FFmpeg master branch and then cherry-picked into the new 4.3
>> branch after the main FFmpeg merge.
>>
>> I am afraid that even if we get all these changes made in MythTV/FFmpeg
>> master, that the merge of FFmpeg/FFmpeg that I must do after that will
>> fail because of the large number of changes.
>>
>> Where there are new functions to be added, can we add them to a separate
>> source file that is specific to MythTV? This would likely make things a
>> lot easier.
>>
>> Let me know what you want to do. At the moment I am stuck.
>>
>> Peter
>>
>>
>>
Hi Mark
It looks like all of most of your commits are related to v4l2.
David Hampton has a bunch of commits which seem to be mainly related to
compiler warnings.
I would like to propose this:
I can create a new branch for the ffmpeg-sync (devel/ffmpeg4.3). I will
update FFmpeg to v4.3 in that branch, with none of the commits to ffmpeg
since the last sync (2019/11/05). MythTV compile will likely fail, since
there are changes that depend on your v4l2 code.
Then you can re-apply your v4l2 changes. To avoid future problems, you
can make the changes in the MythTV/FFmpeg repository, master version and
cherry-pick them into the release/4.3 branch there, and apply them to
MythTV.
Is it possible to create separate new source files for the new
functions? I know there were several functions added in your changes,
and there should be no reason they cannot be in a separate file. That
would reduce the chance of conflicts in future, or at least make them
easier to resolve. If those are later included in the base code by the
ffmpeg team, we can then delete the separate source file.
I see one comment is "updating to latest ffmpeg master code". If you
need to do that, perhaps we should do a merge from ffmpeg master to get
the new code.
I can help with any of this. If you prefer you can add your changes to
the mythtv repository, then let me know and I will include them in
MythTV/FFmpeg right away, rather than waiting for the next sync.
To David:
I would like to recommend against making changes to ffmpeg code that are
solely to fix warnings or for cosmetic items. This can cause conflicts
when merging in new releases of ffmpeg. You can try submitting them to
the FFmpeg team for inclusion in a future release.
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