Mailing List Archive

On 11/10/21 8:26 AM, Piotr Oniszczuk wrote:
> Guys,
>
> I have FFmpeg MythTV patches implementing v4l2_request APIs used to HW decode MPEG2/VP8/VP9/H264/HEVC.
> v4l2_request APIs is de-facto standard APIs used on Linux in ARM world to access HW decoders for HW assisted video decoding.
>
> v4l2_request is used by:
> - Allwiner SOC
> - Rockchip SOC
> - Freescale
> - Broadcom (RPI4 HVEC)
> - other
>
> more details: https://github.com/warpme/minimyth2#hardware-video-decode-support
>
> HW accell with code i have works well on current master: https://github.com/warpme/minimyth2/blob/master/video-test-summary.txt
>
> Pls let me know how you want (and do you want at all?) to include this functionality into MythTV.
>
> br
>
>
>
That sounds good. Does it work with the new ffmpeg (branch
devel/ffmpeg-resync in github)? I will be merging that into master
sometime soon if all is well.

Are there patches to ffmpeg code itself or only to mythtv code? Patches
to ffmpeg code will have to go into our MythTV/FFmpeg repository and be
merged into the mythtv repository.

If you have patches to include the preference is to open a pull request.
If you prefer you can open a ticket with patches. Let me know if you
have a pull request or patches, I can get them installed for you if they
look good. It will be better for all if your changes are incorporated in
the main code as long as they do not conflict with anything else we are
doing.

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

> That sounds good. Does it work with the new ffmpeg (branch devel/ffmpeg-resync in github)? I will be merging that into master sometime soon if all is well.

Yes. I already prepared &tested ver. for 4.4 FFmeg and it seems work on 4.4 FFmpeg well.

>
> Are there patches to ffmpeg code itself or only to mythtv code?

I have 2 patches:
- one for ffmepg (so applies exclusively only on mythtv/external/FFmpeg)
- one for mythtv/configure

> Patches to ffmpeg code will have to go into our MythTV/FFmpeg repository and be merged into the mythtv repository.
>
> If you have patches to include the preference is to open a pull request. If you prefer you can open a ticket with patches.

Well - i prefer ticket with patches.

> Let me know if you have a pull request or patches,

So maybe good will be do this in following way?
1. You will update FFmpeg to 4.4 in master.
2. I will make sure my v4l2_request code works well with master having updated FFmpeg 4.4.
3. Once p.2 will be good - i'll will provide You ticket with patches applicable for master with FFmpeg4.4.

> I can get them installed for you if they look good. It will be better for all if your changes are incorporated in the main code as long as they do not conflict with anything else we are doing.

So far none conflict is known for me.
I have v4l2_request code in production builds for x86_64 targets where mythtv was build with configure disabling support for v4l2_request and none conflicts nor issues were noticed.
What i need to verify is: compile/run of mythv on Linux kernel without v4l2_request kernel code.

_______________________________________________
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

On Wed, Nov 10, 2021 at 1:26 PM Piotr Oniszczuk
<piotr.oniszczuk@gmail.com> wrote:

> I have FFmpeg MythTV patches implementing v4l2_request APIs used to HW decode MPEG2/VP8/VP9/H264/HEVC.
> v4l2_request APIs is de-facto standard APIs used on Linux in ARM world to access HW decoders for HW assisted video decoding.

Can you share the upstream FFmpeg ticket proposing
those patches, and either an outright rejection (which
might justify the project maintaining an out-of-tree
patch), or an agreement for ongoing integration at
some point in the future?
_______________________________________________
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

>
> Can you share the upstream FFmpeg ticket proposing
> those patches,

exemplary for H264:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2898

Attitude of FFmeg is quite exclusive imho....

> and either an outright rejection (which
> might justify the project maintaining an out-of-tree
> patch),

I think current FOSS default is:
-lets wait for kernel uAPI will be finalised
-implement consumer (FFmpeg) accordingly to finalised kernel uAPI

This is ideal model - but issue is time: looking on history (and ppl motivation erosion) - i suspect we will have FFmpeg ready to consume by MythTV in 2..3 years from now.

So my idea is to go align with kernel LTS cycle: 5.15 is LTS so we have guarantee to have compatible&available kernel with compatible uAPI within 5.15 LTS life cycle.
When uAPI settles & upstream FFmpeg implements - we will do 1 steep upgrade (probably around 2023..2024; probably with minimal updates in consumer (=MythTV) code).

Alternative is wait till kernel uAPI settles, FFmpeg upstream follows = 2023..2024 in MythTV probably.
Going with this effectively means (for me): MythTV frontend on non-Android is only x86_64 PC 100$+ class solution.

_______________________________________________
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