Re: FFmpeg-8.0 Warning

On 9/23/25 11:31 AM, Bruce Dubbs ([email protected] via blfs-dev 
Mailing List) wrote:
> On 9/22/25 3:54 PM, "Douglas R. Reno" ([email protected] via 
> blfs-dev Mailing List) wrote:
>> On 9/20/25 9:02 PM, Zeckma ([email protected] via blfs-dev 
>> Mailing List) wrote:
>>> FFmpeg-8.0 is ABI incompatible with 7.1. BLFS in the development books
>>> has updated to FFmpeg-8.0. Several packages do not yet support
>>> FFmpeg-8.0. Some of our own editing team have been bitten from
>>> incompatibilites, such as:
>>> 1. Unable to watch live streams.
>>> 2. Unable to watch several videos and movies.
>>> 3. Unable to access healthcare portals.
>>> 4. Epic hangs.
>>> 5. Packages fail to build against FFmpeg-8.0 like MLT.
>>>
>>> I estimate these issues won't get fixed for around another month. Thus,
>>> I recommend to NOT upgrade to FFmpeg-8.0 to avoid a lot of headaches
>>> and to ensure compatibility with all the software you currently use.
>>>
>>> If you already upgraded or freshly installed FFmpeg-8.0 on your LFS
>>> system, it would be a good idea to rollback to FFmpeg-7.1.
>>>
>>> We may look into rolling back FFmpeg in the book. We pushed it out
>>> in the book way too early.
>>>
>>> I will send another email when the dust has settled and when it seems
>>> mostly safe to install FFmpeg-8.0.
>>>
>>> Apologies to any users with FFmpeg-8.0 currently installed as a result
>>> of it being in the BLFS development (svn/git) book.
>>>
>>> - Zeckma
>>>
>> I would like to propose to everyone the idea of reverting back to 
>> ffmpeg-7.1 until at least Firefox is fixed.
>>
>> The Epic in question is related to healthcare portals, such as those 
>> for Northwestern Medicine and AdvocateAurora Health Care. These 
>> portals use AVIF images to handle part of their websites. These now 
>> hang on Firefox with ffmpeg-8, and Firefox will have to be killed. If 
>> using ffmpeg-7.1 on the same system, they work just fine.
>
> I am not convinced that we should roll back a package in the 
> *development* book.
>
> We already say on virtually every page: "Development versions of BLFS 
> may not build or run some packages properly if LFS or dependencies 
> have been updated since the most recent stable versions of the books."
>
> It is good that the editors know about the problem, but we need the 
> newer version installed on development systems to test when dependent 
> packages are updated.
>
>   -- Bruce
>
That is true, but it makes development systems completely unusable for 
web browsing. Right now, almost any site that uses multimedia on Firefox 
will hang when ffmpeg-8 is installed. That's going to make it difficult 
to identify if the problem is with ffmpeg or with another package. The 
same may apply to QtWebEngine, I haven't tested that so I can't really 
specify just yet (but can later today while I continue working on 
updates). Epiphany shouldn't be impacted as it uses the gstreamer stack 
rather than ffmpeg.

Xi and Rahul have been trying to work with Firefox upstream on the 
issue, but the proposed fixes have failed and have been rolled back. I 
think we are still way too early to have ffmpeg-8. Even when it does get 
fixed in Firefox, it very likely will NOT be backported upstream as 
Firefox ESR is only updated for security fixes [1], and assumes that 
you're using the same version of all dependencies as you would when the 
first ESR version shipped. This means that Firefox's upstream assumes 
that we're still using the same dependency set from late June - which 
included ffmpeg-7.1.

When it does get fixed for later versions of Firefox, we would have to 
backport significant chunks of code ourselves to get it working again. 
Otherwise, we will have no working multimedia support in Firefox (video 
*and* audio) until the next major ESR version. According to the current 
release schedule [2], that would mean we will have no functional video 
or audio support in Firefox until potentially July 21, 2026 - with the 
release of Firefox 153.0. Backporting the chunks of code also adds 
significant risk, as we would need to maintain that patchset if Firefox 
breaks and we'd also be on our own if there are any bugs in it.

The only alternative I can reasonably see is to change to the non-ESR 
variant of Firefox if we don't want to do backports, or if we don't 
downgrade to ffmpeg-7.1. That still needs us to wait until we have a new 
version of Firefox that is confirmed to actually fix the problem. The 
bug report can be found at [3].

[1] https://support.mozilla.org/en-US/kb/firefox-esr-release-cycle : 
"Maintenance of each ESR through point releases is limited to 
high-risk/high-impact security vulnerabilities, and in rare cases may 
also include off-schedule releases that address live security 
vulnerabilities. Backports of any functional enhancements and/or 
stability fixes are not in scope."

[2] https://whattrainisitnow.com/calendar/

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1962139

- Doug

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page