Please add better version management in the pkg install.

Thanks, this effectively answers my question about your access to ampere* and beefy* hosts.

SirDice said:
… You get to see this for example: http://beefy3.nyi.freebsd.org/build.html?mastername=114amd64-quarterly&build=039c0c283e0f …
Click to expand...

– not me.

We plebs get to see this, for example:
1623591406719.png

<https://old.reddit.com/r/freebsd/comments/nujgxe/-/h1gv3ra/?context=2 >

I can find my way around poudriere build logs on my own computer and elsewhere.

There must be good reasons for no public access to ampere* and beefy* hosts. I have no argument, but it leaves us somewhat in the dark.
 
grahamperrin said:
Thanks, this effectively answers my question about your access to ampere* and beefy* hosts.



– not me.

We plebs get to see this, for example:
View attachment 10172
<https://old.reddit.com/r/freebsd/comments/nujgxe/-/h1gv3ra/?context=2 >

I can find my way around poudriere build logs on my own computer and elsewhere.

There must be good reasons for no public access to ampere* and beefy* hosts. I have no argument, but it leaves us somewhat in the dark.
Click to expand...
Funny... I clicked the URL provided by SirDice , and got to beefy3 just fine, no special config needed. This suggests a network hiccup somewhere along the way. Just hit f5.
 
diizzy said:
By flags I assume you're referring to options and that's not true, the default options are a tradeoff between functionality, dependencies and potential conflicts. Think of it as "this should serve the vast majority of users fine".
Click to expand...
Yeah, until you try multimedia/vlc. The pre-compiled package has so few options enabled, subtitles didn't work at all, and there was no x264/x265... I don't think that would exactly "serve vast majority of users just fine". That was the minimum needed to even run VLC without conflicting with other ports. But compiling VLC with all the Makefile flags / options turned on - that created an install that had everything VLC is famous for.

Oh, and BTW - 'Conflicts' within a given ports tree usually happen when 2 or more different ports try to install different versions of the same lib to the same place - e.g., libglut.so from graphics/freeglut v.3.0 or libglut.so from graphics/freeglut v.2.4... but that is usually taken care of BEFORE the ports even make it into the ports tree that public can download.
 
astyle said:
Yeah, until you try multimedia/vlc. The pre-compiled package has so few options enabled, subtitles didn't work at all, and there was no x264/x265... I don't think that would exactly "serve vast majority of users just fine". That was the minimum needed to even run VLC without conflicting with other ports. But compiling VLC with all the Makefile flags / options turned on - that created an install that had everything VLC is famous for.

Oh, and BTW - 'Conflicts' within a given ports tree usually happen when 2 or more different ports try to install different versions of the same lib to the same place - e.g., libglut.so from graphics/freeglut v.3.0 or libglut.so from graphics/freeglut v.2.4... but that is usually taken care of BEFORE the ports even make it into the ports tree that public can download.
Click to expand...
That's one port and I honestly think it's an oversight, submit a PR that enableds libass and you should be fine. I don't see why you'd need x264 and x265 as they're provided by ffmpeg.
As a sidenote, mpv has support out of the box from what I can tell.
 
grahamperrin said:
Thanks, this effectively answers my question about your access to ampere* and beefy* hosts.



– not me.

We plebs get to see this, for example:
View attachment 10172
<https://old.reddit.com/r/freebsd/comments/nujgxe/-/h1gv3ra/?context=2 >

I can find my way around poudriere build logs on my own computer and elsewhere.

There must be good reasons for no public access to ampere* and beefy* hosts. I have no argument, but it leaves us somewhat in the dark.
Click to expand...

I think this is IPv6 only.
 
diizzy said:
That's one port and I honestly think it's an oversight, submit a PR that enableds libass and you should be fine. I don't see why you'd need x264 and x265 as they're provided by ffmpeg.
As a sidenote, mpv has support out of the box from what I can tell.
Click to expand...
I want to watch my animes tonight, and not have to hunt for the links to do all that, and then wait for the devs to finally pay attention to my PR and make it available. I'd do that kind of thing (submit a PR) with KDE and Wayland, then I can just sit back and wait. Besides, you can compile ffmpeg without x264/265. Separate ports. FWIW, ffmpeg comes without those 2 enabled in the default config.

Besides, who'd want to spend time fine-tuning every single one of those 40K+ ports? the devs just do the minimum to get clang to shut up and build, and to be able to power through the entire collection without stopping.
 
diizzy said:
astyle

256593 – multimedia/vlc: Enable support for subtitles by default and add missing deps

bugs.freebsd.org bugs.freebsd.org

Out of curiosity, why do you need encoding support in vlc (decoding is already handled by ffmpeg) for your anime?
I would personally however recommend mpv over VLC for playing video though. =)
Click to expand...
To reply to that, you'd need to know how the software is structured.
  1. FFmpeg uses truckloads of different libs to handle encoding and decoding. Most of those libs are actually separate ports in FreeBSD. You can compile FFmpeg without those libs, but then it won't be quite as capable.
  2. x264, x265, and libASS (ASS stands for Advanced Sub Station alpha, BTW) are actually separate sub-projects from the VLC project (don't believe me, go to videolan.org to check that out). They are separate ports. And yes, that's what VLC uses for decoding - not ffmpeg proper.
  3. FFmpeg can be compiled against the exact same version of the libs I mentioned in item 2, but ffmpeg proper is not a backend to VLC.
  4. FWIW, mpv is compiled using exact same libs as VLC and FFmpeg. I prefer VLC because it has a richer UI, which offers me options and fine-grained control. If you compile VLC with all the possible options enabled, it's quite functional.
 
It's getting off topic but this is the last time I'll answer this... ;-)

1. Yes? FFmpeg can make use of different external libraries however most are actually not for decoding video itself instead encoding, handing other types of data (subtitles etc), APIs, and so on which wouldn't affect your
2. The VideoLAN organisation were indeed involved in developing (lib)x264 which is an encoder .
Reference: https://code.videolan.org/videolan/x264/ "x264, the best and fastest H.264 encoder"
(lib)x265 which is based off (lib)x264 were however developed by MultiCoreWave and not VideoLAN organisation
Reference: https://en.wikipedia.org/wiki/X265
libass were initally developed by Evgeniy Stepanov (not a VideoLAN organisation member of affiliate as far as I can tell) and several years later Grigori Goronzy continued who is listed as a member however it's no clear from a quick view if work was done affiliated with VideoLAN or not. Not that this really matters except for libass which handles a few subtitle formats that VLC supports (not all though).
I also think you've misunderstood a bit what each library does, (lib)x264 and (lib)x265 are only used for encoding as that's what they're designed to do.
code.videolan.org

configure.ac · 3.0.15 · VideoLAN / VLC · GitLab

VLC: the ultimate media player
code.videolan.org code.videolan.org
code.videolan.org

modules/codec/x265.c · 3.0.15 · VideoLAN / VLC · GitLab

VLC: the ultimate media player
code.videolan.org code.videolan.org
code.videolan.org

configure.ac · 3.0.15 · VideoLAN / VLC · GitLab

VLC: the ultimate media player
code.videolan.org code.videolan.org
code.videolan.org

modules/codec/x264.c · 3.0.15 · VideoLAN / VLC · GitLab

VLC: the ultimate media player
code.videolan.org code.videolan.org
3. FFmpeg does however handle the bulk of all formats that VLC supports
https://code.videolan.org/videolan/vlc/-/blob/3.0.15/modules/codec/avcodec/avcodec.c#L71 (feel free to dig around more in the source code if you want)
4. That's fine however the render in mpv and mkv support were (at least a few years back) considered better compared VLC but both will do fine for most work and there might be as big of a performance gap these days.
 
A few things, though I guess it's gotten off-topic. I believe the ffmpeg default package handles x264 and x265--I submitted a PR for that years ago and they did it in two days or so.

I install it from pkg. Just doublechecked it definitely enables x264 and 265. (And ass, but not sure if that was under discussion).
 
scottro said:
A few things, though I guess it's gotten off-topic. I believe the ffmpeg default package handles x264 and x265--I submitted a PR for that years ago and they did it in two days or so.

I install it from pkg. Just doublechecked it definitely enables x264 and 265. (And ass, but not sure if that was under discussion).
Click to expand...
Can't exactly count on being that lucky with packages after submitting a PR... For example, audio/lash has no maintainer, is marked as 'broken', v. 0.5.14 is the one in ports, nobody bothered to prune it because it's an optional dependency for audio/ardour6 (you'll see that only with a # make config in /usr/ports/audio/ardour6). The most recent version of LASH is 0.6.0 (per GNU's git repo), but even that is circa 2008... My point is, it would be pointless to submit a PR for an abandoned port that was never properly pruned out of the ports tree.

Having studied a bit on the process for making a change to the FreeBSD's pre-compiled packages - I can say that there's not that many devs/projects who'd have a good enough handle on the process to do it as fast as was the case for you...
 
You must log in or register to reply here.
Back
Top