@p_ The DRM API doesn't provide what you need, like the port's DP/HDMI spec level and display spec level so you can't know whether the cable is causing an issue. Also drivers do wayyy too many things behind the scenes, like Full/Limited range RGB that's always reported as "Auto" to DRM, so you can't know but only force this, and DP compression which is also auto, so you can't know whether its used or not.
libdrm development moves at glacial pace and driver devs want "just werks lul" approach.
Character songs are a goldmine. They give songwriters a chance to write something they like without the pressure of selling and without compromises seiyuu albums have (where singing > music, always).
GochiUsa has more than 50 CDs released ATM and counting, which have a lot of good songs there that hardly anyone except fans will hear.
Then there's Haganai, where in a bonus song Kanahana and Iguchi Yuuka call each other slurs for 5 minutes. That lyricist went on to write most SAO character songs.
@sir Rust is the worst in that respect. You can easily NIH a bitstream writer or you can do it the rust way, use a black box unmaintained bitstream writer that you cannot touch. This made debugging a nightmare.
Or how you could write your own threading code or you could let rayon parallelize a for loop for you. And since it understands nothing about your code, you don't get the performance you'd expect.
But if you don't use all crates or use unsafe code, you're an enemy to the community.
Love Live is a disgusting, career-destroying, super-commerialized representation of everything wrong with the idol industry. "Let's offer a bunch of new voice actresses the chance to be idols, make them withdraw from voice acting, overwork them, and when they're too old and shaggy we'll just f̶i̶r̶e̶ graduate them back to a now non-existing career."
Songs - waste of good songwriters forced to write crap.
Anime - cliche melodrama central.
They can't afford to do anything different and be hated.
Bitmap subs were a terrible idea for DVDs, and even though they had a chance to fix it, they kept it for BDs.
Instead of a <custom bitmap atlas> and transmitting <indices to the atlas> just use OTF/TTF. Rasterization is cheap, will always look better than bitmap, and you can still send <custom unicode>.
And then the subs can be extracted without OCR (seriously, OCR to recover subtitles!) and the "intellectual property stealking sub websites" won't be filled with OCR typos.
I'm pretty sure now that a good quality white chocolate tastes the best to me.
Normal milk chocolate can be great, but its hard to find a good ratio. With orange flavor can taste incredible.
Dark is acquired taste like coffee and some sort of loudness war is going on where only 90%+ dark is considered good pure real chocolate by some.
Never managed to try ruby chocolate yet, aside from in kitkats, it was okay.
Fun fact, some countries don't consider white chocolate actual chocolate. Bureaucrats.
48000Hz / 960 samples = 20 ms.
A big backer of Opus was the telephony industry (cisco and their phones). The have such an old infra that they can only handle an integer number of packets a second.
So instead of using 1024 sample frames like every other codec ever they choose a messed up 960 to keep it integer. And fix it at 48Khz too.
Why weren't allowed 24/12/6Khz? They're not common rates, its a codec meant for the internet (but not really because of cisco) and its simpler not to.
@Wolf480pl Use AAC-HEv2 then for your audiophile needs. You encode everything at half the samplerate (subsampling by dropping samples without dither, state of the art), then through bad upsampling and worse filters you get a bunch of noise that vaguely resembles the original signal. Bonus points for no stereo because parametric stereo is really really horribad.
Oh, and you still get confused users by this, which encode 48Khz signals at 96Khz.
@Wolf480pl Sure you can. Though since Opus lowpasses everything at 20Khz by spec (and libopus highpasses at ~10Hz for little reason) expect to get 16Khz less bandwidth below the 96Khz nyquist frequency.
Opus encodes 48Khz signals, period. It may internally resample because of layers and other things (low bitrate/voip only), but it has to output at 48Khz.
Ogg's header has a sample rate field. What does opusenc put in that field? The original samplerate of the file.
What does opusdec do with that field. Downsample/upsample to that rate. For no reason. Not in spec. Nothing else does this, because containers lie and you can't trust them, especially ogg.
This leads to some confused users. Grrr.
Found some more unintentional #glitchart.
I think this one had to do with a botched shift from 8bit to signed 16bit. And some sort of chroma desync too.
@Wolf480pl Yes, if there's even 1 pair then you can take a shortcut for those 2 and swap them, though it can be slower (because branching) if they're in not so nice positions.
Otherwise, for a chained/closed LUT you need to apply it out of place for the fastest performance. Or burn it into the FFT if you only need to support exactly 1 direction and transform length.
@Wolf480pl Suppose  needs to go to . The element in  however needs to go to . The element in  needs to go to .... and so on, until the very last element, which will of course go to .
Codec researcher, x86 assembly and Vulkan expert. As expected.
Had nothing to do with x264. Most unexpected.
A Mastodon instance for people interested in multimedia, codecs, assembly, SIMD, and the occasional weeb stuff.