[mythtv] FFmpeg Resync

[Piotr Oniszczuk]

> Wiadomość napisana przez Peter Bennett <pb.mythtv at 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….