Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 09 Sep 2021 05:45:04 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 258381] multimedia/libx264: This library inappropriately lowered the scheduling priority of the process using it
Message-ID:  <bug-258381-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258381

            Bug ID: 258381
           Summary: multimedia/libx264: This library inappropriately
                    lowered the scheduling priority of the process using
                    it
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: koobs@FreeBSD.org
          Reporter: msl0000023508@gmail.com
          Assignee: koobs@FreeBSD.org
             Flags: maintainer-feedback?(koobs@FreeBSD.org)
 Attachment #227779 text/plain
         mime type:

Created attachment 227779
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D227779&action=
=3Dedit
multimedia/x264/files/patch-common-osdep.h

This library contains a logic that will attempting to lower the scheduling
priority of the encoding thread, if multi-threading is enabled. However it =
is
flawed as it will lower the priority of the entire process (by calling
nice(3)), not only that specific thread; in fact in will lower the process
scheduling priority every time when a encoding thread is created, the prior=
ity
of whole process will be set to the lowest (nice=3D20) as a result.
This behavior is highly undesirable because it may result in losing real-ti=
me
proformance of other threads of the library consumer, such as ffmpeg(1);
libx264, as a library, shouldn't change the process priority, affecting the
entire process of any program that may using this library.
Another issue is that under some scenarios, lowering the scheduling priorit=
y of
encoding threads isn't preferable at all, because the video source or target
could be a live stream, thus requiring real-time proformance to encode it.
A patch is attached that disables this behavior.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-258381-7788>