Mailing List Archive

FFmpeg Resync
I have resynced FFmpeg 4.3 to MythTV (master) and placed the result in
new branch "devel/ffpeg-resync".

The changes made to FFmpeg code in the MythTV repository since the last
sync to 4.2 have been discarded.

Mark - If your changes are necessary please

1. Apply them to the MythTV/FFmpeg repository, master branch.
2. Cherry-pick them into the MythTV/FFmpeg repository, release/4.3 branch.
3. Copy the code into the MythTV/mythtv repository, master branch

Note: The code in MythTV/mythtv repository master branch, FFmpeg
directory is a copy of the code in MythTV/FFmpeg repository, release/4.3
branch. so after making changes in MythTV/FFmpeg repository and
cherry-picking into release/4.3 you can just copy the modules over into
the MythTv/mythtv repository master branch without fear of losing any
changes.

Mark and David please note:

Bear in mind the FFmpeg code needs to be resynced from time to time.
Please do not make any cosmetic changes to FFmpeg or changes designed
only to remove compiler warnings.

If you need to make FFmpeg changes please follow the above procedure, so
that the changes are in the MythTV/FFmpeg repository and ready for the
next resync.

If you are adding any new functions please consider creating a new
source file for them.

It would be helpful to note with comments that a change has been made
for MythTV so that when conflicts occur in the resync it makes things
clearer.

In future, if there is new code, that you need, in FFmpeg that is not
yet MythTV, let me know and hopefully we could include it by
cherry-picking from the main FFmpeg, rather than copying the code and
causing a conflict later.

Here is a list of changes that have been lost in the resync (Only the
changes in the FFmpeg directory have been lost, if the commit includes
other changes in MythTV they will still be there):

git log mythtv/external/FFmpeg/
* 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
*   cadc149225 2019/11/06 Mark Kendall  : Merge branch 'master' into
devel/2019-render
|\
| * b99b0424ca 2019/11/05 Peter Bennett : FFmpeg: Sync to latest 4.2 source

David: Note I had to add __STDC_CONSTANT_MACROS to libmythtv.pro to get
the compile to work.

David: I see a lot of warnings about "register" being obsolete. I hope
there is some way of avoiding making a change to FFmpeg code for this.

Mark; Once you are happy with this we can merge it back into master.

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 Resync [ In reply to ]
On Tue, 2020-06-23 at 14:55 -0400, Peter Bennett wrote:
> I have resynced FFmpeg 4.3 to MythTV (master) and placed the result
> in
> new branch "devel/ffpeg-resync".
>
> The changes made to FFmpeg code in the MythTV repository since the
> last
> sync to 4.2 have been discarded.
>
> Mark - If your changes are necessary please
>
> 1. Apply them to the MythTV/FFmpeg repository, master branch.
> 2. Cherry-pick them into the MythTV/FFmpeg repository, release/4.3
> branch.
> 3. Copy the code into the MythTV/mythtv repository, master branch
>
> Note: The code in MythTV/mythtv repository master branch, FFmpeg
> directory is a copy of the code in MythTV/FFmpeg repository,
> release/4.3
> branch. so after making changes in MythTV/FFmpeg repository and
> cherry-picking into release/4.3 you can just copy the modules over
> into
> the MythTv/mythtv repository master branch without fear of losing
> any
> changes.
>
> Mark and David please note:
>
> Bear in mind the FFmpeg code needs to be resynced from time to time.
> Please do not make any cosmetic changes to FFmpeg or changes
> designed
> only to remove compiler warnings.
>
> If you need to make FFmpeg changes please follow the above procedure,
> so
> that the changes are in the MythTV/FFmpeg repository and ready for
> the
> next resync.
>
> If you are adding any new functions please consider creating a new
> source file for them.
>
> It would be helpful to note with comments that a change has been
> made
> for MythTV so that when conflicts occur in the resync it makes
> things
> clearer.
>
> In future, if there is new code, that you need, in FFmpeg that is
> not
> yet MythTV, let me know and hopefully we could include it by
> cherry-picking from the main FFmpeg, rather than copying the code
> and
> causing a conflict later.
>
> Here is a list of changes that have been lost in the resync (Only
> the
> changes in the FFmpeg directory have been lost, if the commit
> includes
> other changes in MythTV they will still be there):
>
> git log mythtv/external/FFmpeg/
> * 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
> * cadc149225 2019/11/06 Mark Kendall : Merge branch 'master' into
> devel/2019-render
> > \
> > * b99b0424ca 2019/11/05 Peter Bennett : FFmpeg: Sync to latest 4.2
> > source
>

Peter,

> David: Note I had to add __STDC_CONSTANT_MACROS to libmythtv.pro to
> get the compile to work.

That flag once meant something, but it hasn't in the last decade or so
because the items that used to be dependent on that flag are now always
present. Requiring that flag to be present changes nothing about the
compilation. Since you reverted 459fccb5aa you added back the check for
a flag which is no longer supplied by MythTV, so you needed to add back
the declaration of the flag.

> David: I see a lot of warnings about "register" being obsolete. I
> hope there is some way of avoiding making a change to FFmpeg code for
> this.

I have a one line workaround that can go in the MythTV sources, but
there are still a large number of "unused parameter" warnings caused by
including get_bits.h that can't be fixed without changing the FFmpeg
sources. If I change get_bits.h to fix the the unused parameter
warnings, I can fix the storage class specifier warnings at the same
time with the same one line addition (but in get_bits.h).

There's one other patch I'd like to keep that adds two comments (of
three lines each). This will allow me to enable automated nightly
checking for nullptr dereferences in MythTV, without producing a bunch
of warning messages that point at FFmpeg.

I would be happy to commit both these sets of change using the
procedure you outlined above. Its a total of nine lines of comments,
and three lines of other stuff.

David


_______________________________________________
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 Resync [ In reply to ]
> Wiadomo?? napisana przez Peter Bennett <pb.mythtv@gmail.com> w dniu 23.06.2020, o godz. 20:55:
>
> I have resynced FFmpeg 4.3 to MythTV (master) and placed the result in new branch "devel/ffpeg-resync".
>
> The changes made to FFmpeg code in the MythTV repository since the last sync to 4.2 have been discarded.
>
> Mark - If your changes are necessary please
>
> 1. Apply them to the MythTV/FFmpeg repository, master branch.
> 2. Cherry-pick them into the MythTV/FFmpeg repository, release/4.3 branch.
> 3. Copy the code into the MythTV/mythtv repository, master branch
>
> Note: The code in MythTV/mythtv repository master branch, FFmpeg directory is a copy of the code in MythTV/FFmpeg repository, release/4.3 branch. so after making changes in MythTV/FFmpeg repository and cherry-picking into release/4.3 you can just copy the modules over into the MythTv/mythtv repository master branch without fear of losing any changes.
>

Guys,

It looks like talk here is about v4l2 related code…

Just my 0.02$ regarding thing:

I believe we should consider to address 3 major areas here:

1. Fixes in v4l2_m2m for stateful video_decoders not upstreamed in ffmpeg (usually required for better user experience or better stability)

2. DRM_PRIME required for low CPU load in systems with separate video decoder & video renderer (required for stateful and stateless video decoders)

3. V4L2_request for stateless video decoders in systems from p.2

p.2 & p.3 seems to be already started to upstreaming in ffmpeg but look like thing is a bit stalled.


Ad p.2:
Aman already submitted into ffmpeg-devel DRM_PRIME code:

https://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/249359.html

It looks like ffmpeg team not moving forward with this :-)
I have some hypothesis here(*)

Ad p.3:
Jonas already submitted into ffmpeg-devl V4L2_request code:

http://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242316.html

Again - it looks like ffmpeg team not moving forward with this….
Also here I have some thoughts(**)

From our perspective we may:

a\wait till upstream (ffmpeg) will accept final DRM_PRIME/V4l2_request code and then incorporate this into out code

b\go now with available code and re-sync when upstream will be ready.

From history - option a\ may take years :-\

I would opt for b\ as this is unblocking steep to have myth working on all platforms from p.2 (effectively all non decode-renderer integrated hw like Nvidia/Intel/AMD)

Going with b\ we may look on:

https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3

This code is v4l2_request baselined on current 4.3 ffmpeg

For DRM_PRIME code is here:

https://github.com/lrusak/FFmpeg/commits/v4l2-drmprime-v5

Boring stuff of adding v4l2_request code to mythtv configure I already addressed here:

https://github.com/warpme/minimyth2/blob/master/script/myth-master/mythtv/files/0163-configure-add-v4l2request-support.patch


let me know what you think…



(*)
Excluding lack-of-time hypothesis - I suspect issue might be related to perception that DRM_PRIME is exclusively Linux thing and ffmpeg team don’t want include single platform (Linux) & single hardware (DRM) specific code in highly universal ffmpeg. This is (IMHO) false perception as DRM_PRIME has also EGL_DMABUF_EXPORT which is based on well known EGL extension (so no specific platform). DMABUF is still Linux specific but low-level platform specific implementation of zero-copy on UMA or DMA assisted on NUMA is always platform specific so this „issue" is immanent to aspect of providing uncompressed frame from decoder to renderer. If ffmpeg guys wan to realise this effectively - they will have ALWAYS „issue” of trapping in platform specific things.


(**)
This issue seems (for me) chicken-egg problem….
So far required part of v4l2 kernel private headers is not exposed - so ffmpeg can’t consume kernel functionality due no public kernel api for it.
Official argument to not expose yet this part of headers is lack of required stability in api.
Issue is that this state is since almost year and seems to be stalled.
I reading this as deadlock case where: project stalls and effectively will deliver in undefined future due perceived quality not reaching desired quality.
Here i think we (KODI & MythTV) may help with „proving-by-working-case” that quality is enough to move forward….





_______________________________________________
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