[Bug 238773] multimedia/x265: Only highest bit-depth profile is built when multiple (bit-depth OPTIONS) are selected

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238773

--- Comment #24 from Mikhail Teterin <mi at FreeBSD.org> ---
(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 8bit
(only) and should remain 8bit by default even if other widths will be enabled
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=true). You just
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 mistake I
cannot (easily) correct, because the report was filed anonymously. I doubt,
upstream developers would use a FreeBSD-machine, though. But they may be able
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-depth,
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 -- while
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 turn
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...

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