@sjw Apparently there's some weird shit going on with the container for the opus file. I can get ffplay to play it. The AAC does not work at all: "Audio object type 42 is not implemented."
> The Fraunhofer FDK AAC codec library. This is currently the highest-quality AAC encoder available with ffmpeg (except on macOS, see below). Requires ffmpeg to be configured with --enable-libfdk-aac (and additionally --enable-nonfree
@sjw@p As far as copyright goes yeah but honestly it's weird they consider it free given the comments about it[1], Debian rejects it and I think OSI also rejected it (at least it's not in their list of licences).
@sjw That is about the license: a license is not a codebase. The license is a free license. They did not say that the codebase is free, and with good reason. The license carves a loophole explicitly saying that it does not cover patents and that you may need patents. They explicitly avoided saying anything about the disposition of the code itself.
The license appears to be free. That does not say anything about the codebase. If you did a release of Pleroma where you had copied the Windows source code into the Pleroma codebase, the AGPL would still be a free license, but what you were distributing would not be free software.
@p@sjw Except Debian considers it non-free because of the explicit patent requirement *in* the license restricts the fields of endeavour clause, which is explicitly present in DFSG (and Open-Source). Software patents being particularly nasty.
@lanodan@sjw Yeah, I mean, my point is that a codebase's status is independent of the purported licensing. I think the distinction matters a great deal here if they are talking about patents.
> the explicit patent requirement *in* the license restricts the fields of endeavour clause,
That makes sense. It's not going to be GPL-compatible for that reason, I can see an argument that it doesn't qualify as free software at all. I think it gets around it by saying "Maybe some patent licensing is required. No patent license grants are provided." Like, I could release some software and license it under the FDK and as long as I did not actually publish any patented software under that license, it would be a free codebase. The AT&T Public License granted a patent license but revoked it if you modified the code: the patents being asserted in the license and the different status if the user modifies it are probably the reasons. You lose rights that you were granted for altering the code. The FDK doesn't grant any of those rights and doesn't assert them or revoke them: it just suggests that you apply for a patent license. The GPLv3 requires a patent grant but the GPLv2 had this in the preamble:
> Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
@sjw@iska@p hevc and svt-av1 are still pretty slow. they have a lot more filters to work with so trialing the combinations of filters is quite onerous.
i think it will remain this way until neural heuristics become a commonplace thing. there was one paper about a chinese codec (i forgar the paper) where they did this and it does work fine.
basically using the slow encoders to brute force reference material and then training neural networks to predict filter chains directly, it does make these things a lot more performant.
@icedquinn@blob.cat@sjw@bae.st@p@freespeechextremist.com just remembered how I reencoded a 4k bitrate crushing video from vp8 to av1 It took 24 hours but halved the size However, I forgot to move it from /dev/shm to a persistent location :acat_flop:
@sjw@iska@p x264 encoding is fast because there are hardware primitives for it. same as common algorithms like SHA and AES.
also a lot of fiddling from frabrice if i recall.
the current gen codecs have a *lot* more decisions that have to be made. h264 and vp8 always cut an image in to fixed size blocks, while h265 and vp9/av1 can do that but can also choose to split images in to jigsaws of blocks.
@icedquinn@iska@p >hevc and svt-av1 are still pretty slow. they have a lot more filters to work with so trialing the combinations of filters is quite onerous.
Yeah but svt-av1 is pretty decent now. It actually seems faster than x265
>i think it will remain this way until neural heuristics become a commonplace thing. there was one paper about a chinese codec (i forgar the paper) where they did this and it does work fine.
More than likely software encoding will never be fast again. X264 was kind of a fluke that happened at just the right time. The future will be ASICs, FPGAs, and likely a NPUs for AI assisted hardware encoding.
>basically using the slow encoders to brute force reference material and then training neural networks to predict filter chains directly, it does make these things a lot more performant.
I'm more interested in a fully AI video encoding/decoding model. Hard to say if it'd be practical over AI assisted ASIC but if you were to give an AI access to an FPGA with the task of encoding the video quickly and efficiently things could get very interesting.
@icedquinn@iska@p yee I'm aware. Just mostly comparing x264 to the codecs that came before and after it. Vpx has always sucked tho. I haven't had a chance to test SVT-VP9 yet but I've heard it also sucks. That was a few years ago tho.
@istvan@p@sjw Sadly USAC/xHE-AAC® that sjw used for a.m4a is *not* MP3 but a particularly proprietary one of the MP4 family of codecs (regular AAC being fine).
@terryenglish@icedquinn@p oh yeah just rename your .opus files to .ogg or .oga and replay gain should work. I ran into that same problem a few years ago.
@icedquinn@iska@p nah there were a good number of steaming services that used it because they didn't want to pay for h.265 and Google had already done the leg work of getting a hardware accelerated vp9 decoder into most devices.
@TURBORETARD9000@sjw@p@lanodan I’m the guy who has been going through all the patents for gemstone cuts, doing the trig with a protractor, and publishing open CAD and cutting instructions.