From owner-freebsd-ports-bugs@freebsd.org Thu Jan 23 02:58:41 2020 Return-Path: Delivered-To: freebsd-ports-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4D718229718 for ; Thu, 23 Jan 2020 02:58:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4836RP1R6yz3RF6 for ; Thu, 23 Jan 2020 02:58:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3130C229717; Thu, 23 Jan 2020 02:58:41 +0000 (UTC) Delivered-To: ports-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 30FA9229716 for ; Thu, 23 Jan 2020 02:58:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4836RP0Y3Sz3RF5 for ; Thu, 23 Jan 2020 02:58:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0A5907DE4 for ; Thu, 23 Jan 2020 02:58:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 00N2weFW092818 for ; Thu, 23 Jan 2020 02:58:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 00N2wevL092817 for ports-bugs@FreeBSD.org; Thu, 23 Jan 2020 02:58:40 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 238773] multimedia/x265: Only highest bit-depth profile is built when multiple (bit-depth OPTIONS) are selected Date: Thu, 23 Jan 2020 02:58:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, needs-patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mi@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 02:58:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238773 --- Comment #24 from Mikhail Teterin --- (In reply to daniel.engberg.lists from comment #21) > 8-bit should always be the default and that's the bit depth devices > for sure are to support if they understand H.265 aka HEVC. This seems to be the common sentiment, and I'd agree except for the legacy = of situation -- our _package_ has always been 8bit-only, but the _port_ would = use the different depth if enabled -- this is, what Jamie was pointing out in comment #10. One could say, that people building from source are smart enough to change their settings, except I for one am not such a person myself... I'd fire off "portupgrade" and expect things to "just work" -- and would be upset, if suddenly my program starts behaving differently: if I had, say, 10bit-width enabled, I'd expect it to continue to remain the default... Maybe, that's unavoidable -- because the package has always defaulted to 8b= it (only) and should remain 8bit by default even if other widths will be enabl= ed too from now on. > While your Makefile works it's not very clear what it does My method allows the main part to be built as a "vanilla" cmake-using port = -- without overwriting the do-build and the do-install targets. I think, that'= s a win. I also avoid the cd-ing and mv-ing things around, but that's less important. > why you're building HDR as a separate lib which upstream doesn't > seem recommend Because _your own_ x265-v1.patch did :-) (ENABLE_HDR10_PLUS=3Dtrue). You ju= st weren't installing the result, because you had your own do-install... Now, maybe, that can be a separate option -- but given the general spirit of this discussion, I figured I'll just include it unconditionally. > Are you still on 11.2 or did you upgrade to 11.3? I am on 11.3, actually -- I made a mistake filing that bug-report. A mistak= e I cannot (easily) correct, because the report was filed anonymously. I doubt, upstream developers would use a FreeBSD-machine, though. But they may be ab= le to find the same processor and clang/nasm versions... > I think we should drop the option to select bit depths Considering the effort already spent on developing support for the options,= I'd like to keep it. Whoever was happy building the port with just one bit-dept= h, should be able to continue to have that, even if the default package will include all three. (In reply to Jamie Landeg-Jones from comment #22) > 8bit should be the default, AND should always be included > (it seems to be what everyone else expects Everyone _except_ FreeBSD-users -- who, until the port's inception -- have = used exactly one bit-depth... I'm leaning towards preserving that ability -- whi= le adding the ability to include multiple depths. (In reply to amvandemore from comment #23) > 8 bit is absolutely required because it's the standard bit depth > for any common video of decent quality for some time That's an argument for including 8 bit by default (building a package). But someone configuring the port's options should, in my opinion, be able to tu= rn the 8bit-width off, if they have no use for it for whatever reason... Thank you very much, gentlemen. I really do appreciate both the effort you = put into this ticket and your opinions... --=20 You are receiving this mail because: You are the assignee for the bug.=