• 7 Posts
  • 185 Comments
Joined 8 months ago
cake
Cake day: March 12th, 2024

help-circle
  • The article is pretty bad.

    It argues in bad faith against GitHub, conflates addressing the reader and their own community (suddenly “we …”), fails to see how despite not being FOSS you can be pro FOSS, names the vendor lock-in but fails to present advantages and disadvantages… I think the tone is pretty bad as well.

    For the most part, I dislike when projects and people self-host. It’s a barrier to me to read and participate. Different interface and UX, no account, different needs for registration, Terms of Service and Privacy Policy, unclear long-term stability.

    I like Forgejo and Codeberg. It has a good and well-known user interface, is fast to use, FOSS, and has a centralized platform., and is working on federation which could ease pain points of distributed and split hosting.

    I find SourceHut UI unstructured; very confusing.

    When GitLab came up, there was a time when I used it for my new projects, and moved some onto there, but eventually moved back to GitHub. Hosting it myself at work; self-hosting it is huge, heavy, bloated.

    The main reasons I still use GitHub are that it is free, feature-rich, fast, familiar, and one platform. I much prefer a low barrier to entry and uniform between projects as long as GitHub acts well enough, even if it is not FOSS itself.

    I would hate to see people follow this article and further spread out FOSS, increasing barriers to entry. I have left exploring projects and contributing because of that barrier on multiple occasions and projects.

    I’m hopeful for Codeberg and Forgejo. Codeberg can serve as a centralized platform already. Should Federation land, it can serve as a base for self-hosted instances, reducing many pain points of a heterogeneous and self-hosted-distributed field.


    Side story: When SourceForge became shit, I created and executed an issue ticket migration for a significant FOSS project. Thankfully we can change platforms like that when you’re not fully locked in but have accessible or natively distributable data.





  • I’ve always used aimp2, but my library broke file path metadata and the fixup tool fails to relocate them. I’ve looked at FOSS and free alternatives, and am not really, fully satisfied with any of them.

    IIRC, I found none of them sufficient. Strawberry, Clementine, Audacious, MusicBee; all have dissatisfactory UI / UI structure for me. Foobar is way too minimal. From my exploration, MusicBee was the most reasonable, acceptable for me. The customizable tab setup is a confusing mess too, but otherwise… I’ve been using that for a while.

    At some point I started implementing my own music player, making use of the BASS library like aimp2 does. But not much has come of that [yet?].

    Maybe I can recover my aimp2 metadata, and will switch back to that.
















  • I will use AVC and HEVC terminology for h264/x264 and h265/x265 respectively.

    For video, you get jumps of compression quality from AVC to HEVC, from 8-bit to 10-bit, and from HEVC to AV1.

    Depending on your source material, changing compression settings, like target quality, variable bitrate, etc, can also have significant gains. It will depend on your source and target though, and may need some testing to get “right”. If you’re looking for the best compression, that may be on a file by file basis, because different kinds of video have significantly different compression behavior or concerns. That’s likely not feasible for a mass of files though.

    Playback compatibility should also be considered. AVC mp4 is the most compatible, right now, if you consider all kinds of and older mobile and embedded devices. If you’re fine with modern or desktop, you can go for the best compression codecs.


    To get an idea of encoding time investment and quality, you can use ffmpeg with default quality settings, and target the different encoding targets.

    AV1 10-bit, Opus audio:

    ffmpeg -i input.mp4 -c:a libopus -c:v libsvtav1 -pix_fmt yuv420p10le out_av1-10bit-opus.mkv
    

    AVC mp4 (when targeting mp4 these codec settings are the default, so in fact don’t have to be specified):

    ffmpeg -i input.mp4 -c:a aac -c:v libx264 -pix_fmt yuv420p out_avc-aac.mp4
    

    HEVC 10-bit, opus:

    ffmpeg -i input.mp4 -c:a libopus -c:v libx265 -pix_fmt yuv420p10le out_hevc-10bit-opus.mkv