xbmc / inputstream.ffmpegdirect

Supports streams opened by FFmpeg's libavformat or Kodi's cURL such as plain TS, HLS and DASH (non-DRM) as well as many others. There is support for Archive/Catchup services where there is a replay window and can timeshift across that span. Also provides timeshift for live streams where rewind/pause and fast-forward would not have been available.
GNU General Public License v2.0
57 stars 40 forks source link

Rectify the inability to compile due to an excessively new version of the compilation toolchain. #252

Open daiaji opened 9 months ago

phunkyfish commented 9 months ago

The header commit is fine. However the bin-utils patch is not.

There will be millions of different Linux installs for the current stable release and this patch could break them. Sorry, buts it’s too risky.

I recommend comping with ffmpeg6 on the Omega dev branch as this likely already runs with your binutils version.

Note that we don’t carry any patches for Linux platforms for ffmpeg. It took us quite a while to get there. I’d prefer not to go back to having them.

daiaji commented 9 months ago

I recommend comping with ffmpeg6 on the Omega dev branch as this likely already runs with your binutils version.

However, the patch to fix src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for 'shr' is still not applied to xbmc's ffmpeg6. Consequently, this patch remains necessary for a successful compilation.

https://gitlab.archlinux.org/archlinux/packaging/packages/kodi On a side note, the official source of Arch Linux has also adopted this patch.

phunkyfish commented 9 months ago

I recommend comping with ffmpeg6 on the Omega dev branch as this likely already runs with your binutils version.

However, the patch to fix src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for 'shr' is still not applied to xbmc's ffmpeg6. Consequently, this patch remains necessary for a successful compilation.

https://gitlab.archlinux.org/archlinux/packaging/packages/kodi On a side note, the official source of Arch Linux has also adopted this patch.

If you are using ffmpeg 6 there should be no reason to compile it yourself. The system one should work ok (hopefully).

daiaji commented 9 months ago

I recommend comping with ffmpeg6 on the Omega dev branch as this likely already runs with your binutils version.

However, the patch to fix src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for 'shr' is still not applied to xbmc's ffmpeg6. Consequently, this patch remains necessary for a successful compilation. https://gitlab.archlinux.org/archlinux/packaging/packages/kodi On a side note, the official source of Arch Linux has also adopted this patch.

If you are using ffmpeg 6 there should be no reason to compile it yourself. The system one should work ok (hopefully).

If I use ffmpeg4.4, I don't need to compile it either, but indeed, the last time I compiled inputstream.ffmpegdirect for Omega, I encountered the same error. It seems that FindFFMPEG.cmake has also malfunctioned.

The only good news is, after some adjustments, my modifications took effect, and at least now I can compile the packages for Nexus.

It seems that if inputstream.ffmpegdirect does not malfunction, the Nexus version can also use the local ffmpeg6?

There will be millions of different Linux installs for the current stable release and this patch could break them. Sorry, buts it’s too risky.

Upon executing a downgrade, I have discerned that the compilation can still proceed smoothly, implying the absence of substantial difficulties

Moreover, if the FindFFMPEG.cmake could work properly, this patch wouldn't be much of a use, but on the contrary, I believe that fixing errors is better than not fixing them. Plus, this is merely a backport of the official ffmpeg patch. The risk is relatively small given that the ffmpeg team has already reviewed the code. And I guess if the new version of inputstream.ffmpegdirect fails to compile, compiling the old version should not be an issue.

Also, do you have any ideas on the testing and fixing of FindFFMPEG.cmake?