Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)U

unfortunate_ferret

@ obelisk_complex @piefed.ca

Posts
5
Comments
223
Joined
5 mo. ago

  • Removed

    The Truth Behind “That’s Just Your Subjective Opinion”

    Jump

  • That's not "a very common way to see it". It's the way it is.

    Facts are independently measurable; there the same for everyone, you always get the same data; there are no exceptions. As you said in another comment, objective reality is what remains true regardless of reference frame.

    Opinions are not independently measurable. Once you have a measurement that holds true across reference frames, you have a fact.

    Objective reality is treated as superior to subjective reality because it's more useful. Subjective reality can be "better" in certain circumstances though, for example as an escape for a mind - abandon your observations of objective reality and replace them with something preferable.

    You have to accept the meanings of words in order to have a meaningful debate about the concepts they carry.

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • If you saw a mushroom cloud, what would you say?

    Jump

  • Yes, it does imply it. It's the most common association for mushroom clouds in our media since the bombs were dropped. Doesn't guarantee it of course, but to act as though "they're unrelated and anyone making the association is ignorant" would be an indefensible position.

  • The English language is peculiar.

    Jump

  • You totally can though. It's a common phrase.

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Sweet as, lmk if you have any questions or run into any issues! 😊

  • People who have been on Lemmy since the very initial reddit API debacle, or before even that, how much do you think it has changed?

    Jump

  • This is how I know I'm old. I consider the "Reddit API debacle" recent history.

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Whether it's an alternative depends on what you use Handbrake for. HISTV can't convert ISO or rip discs, it only converts video files. If you just use Handbrake to get smaller videos, HISTV will work for you without having to use more controls than it would take to launch the space shuttle 😅

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Thanks for your patience, took me a minute to get my VM up and running so I could test the Flatpak, but it's working and with no permissions: https://github.com/obelisk-complex/histv-universal/releases/tag/v2.3.6

    By which I mean "Replace source" works out of the box with no permissions; in order for "Place next to source" output to work, you'll have to give permission to the folder via flatseal (as you noted).

    I've got a few more updates to make - I'm simplifying the UI a little, and I'm adding the ability to transcode AV1 - and then I'll work on getting it building entirely offline in order to submit it to the Flathub store for review. Great suggestion, I appreciate it! (👉ﾟヮﾟ)👉

  • Netflix announces yet another price hike for all tiers, over a year after the last one

    Jump

  • laughs in jellyfin

  • Is cryptocurrency good for anything?

    Jump

  • It's great for sending money abroad. No bank, minimal fees. I use it for that all the time, to send friends gifts for weddings and birthdays and stuff.

    Yes, this requires everyone in the transaction to be on the network and know how to sell cryptocurrency; the question is whether it's useful, not whether it's useful with no caveats 😋

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Ah-ha, thanks for the update on Docker! Saves me going down that rabbit hole 😅

    On the files on the NAS: yep, that's by design. My files are across the WAN, not LAN, so I built it to stage remote files locally before transcoding. It currently pulls a file, transcodes it, and moves it wherever you chose for output. This does mean that going over a network is slow, because you have to wait for the staging and cleanup before doing another file. That's deliberately conservative though; I wanted to avoid saturating networks in case the network operator takes exception to that sort of thing. A secondary benefit is that the disk space required for operations is just twice the size of the source file - very low chance of having to pause a job because the disk monitoring detected there's no room.

    I'll look at putting in an override that disregards the network and treats remote files as local for you!

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Haha thanks! You mean, support them for output, as well as being able to convert from? Last night I outlined adding an "Auto" option for container, which would keep the source container if possible, but the controls I've exposed vs the ones I haven't are a conscious choice, to maximise player compatibility for the outputs without the user having to know anything about codecs, containers, encoders, their hardware, or quality settings. I'm deliberately keeping the options to a minimum because I didn't want to make Handbrake 😅

    As to why I chose these codecs: h264 works on devices from 15+ years ago, and HEVC is compatible back to 2015-16. AV1 is 2020 onwards and requires GPU decoding; that's too new and resource-intensive for my goals with HISTV.

    I'll think about how I could pull this off though. Perhaps a "lite" mode that keeps the original codec and container, or an "auto" mode for codec dropdown too. I think I like the second one better: lets you mix and match keeping container or codec or both, without adding any real complexity to the options.

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Hahaha baby steps! But I'll look at it; if nothing else I think it would be very funny to have the dev equivalent of Jar Jar Binks end the format war by accident (which I say as just a joke; I of course have no idea how complex the issue actually is).

    Edit: Damn dude, you weren't kidding about the challenge. You're right that HISTV won't work for DoVi 5 in its current state - "Fundamental to FFMPEG" does kinda mean "fundamental to HISTV", being that it's basically just a clever wrapper around FFMPEG. That said, if your tooling is ready, I've got a plan to integrate it. The philosophy with HISTV is to preserve whatever we can and fall back gracefully as far as we have to if we can't preserve the current profile, which your tools slot into like they were made for it (Rust Gang represent (👉ﾟヮﾟ)👉).

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Ah, then the real slowness is going to come from having them on a spinning disk HDD. For friends, 3Mbps or 4Mbps target bitrate should be plenty, with the 2x multiplier should be enough to preserve detail. No need to touch anything else, you don't need precision mode for it. Maybe start with 3 and that on just one episode, and see how you go - if you find yourself noticing it looks blocky, bump up to 4Mbps and you'll be golden.

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Fun fact - HISTV actually has two-pass encoding! Though, with enough system RAM you can actually look ahead far enough that you can get the benefits of two-pass in just a single pass. I have a bit about this in the README.md:

    Precision mode

    One checkbox for the best quality the app can produce. It picks the smartest encoding strategy based on how much RAM your system has:

    Your RAMWhat it does
    16GB or moreLooks 250 frames ahead to plan bitrate (single pass)
    8-16GBLooks 120 frames ahead to plan bitrate (single pass)
    Under 8GBScans the whole file first, then encodes (two passes)

    Two-pass only happens when precision mode is on AND the system has less than 8GB RAM AND the file would be CRF-encoded. Reason being those lookaheads above. Lookahead buffers live in memory. On low-RAM systems that buffer would be too large, so the app falls back to two-pass instead and stores the analysis run in a tempfile on disk. To break down each one:

    • Pass 1: Runs ffmpeg with -pass 1 writing to a null output. ffmpeg analyses the entire file and writes a statistics log (the passlog file) describing the complexity of every scene. No actual video is produced - this pass is pure analysis.
    • Pass 2: Runs ffmpeg with -pass 2 using the statistics from pass 1. The encoder now knows what's coming and can distribute bits intelligently across the whole file - spending more on complex scenes, less on simple ones - without needing a large lookahead buffer in RAM. After both passes complete, the passlog temp files are cleaned up.

    The biggest problem with two-pass encoding is the speed. It has to do two passes over the whole file: one analysis, one actually encoding. With a 250-frame lookahead, you're basically just writing your passlog into RAM - and reading from it - as you go. With 120-frame lookahead your CPU will likely catch up to the passlog at times, but you can still write to and read from it as you go, so you still get similar speed, and still close enough in quality that it doesn't really make a difference, in a single pass.

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • You know what? I think I can figure out a way to estimate final file size and display it to the user. It'll only work if "Precision Mode" is off though - that uses "CRF" or "Constant Rate Factor" which basically tells the encoder "be efficient, but make the file as big as it needs to be to look good". As a result there's no way to tell how big the file will end up being - the encoder makes the decision on the fly.

    With "Precision Mode" off, HISTV has two gears:

    1. If your file is already small enough (at or below the target bitrate), it uses "CQP" or "Constant Quantisation Parameter" (the QP I/P numbers), which tells the encoder "Use this quality level for every frame, I don't care how big the file ends up". It's fast and consistent - every frame gets the same treatment.
    2. If your file is too big, it switches to VBR (Variable Bit Rate), which tells the encoder "Stay around this target bitrate, spike up to the peak ceiling on complex scenes, but don't go over". It's how the app actually shrinks files. You can estimate the output size with target mbps * seconds / 8 - so a 60-second clip at 4Mbps lands around 30MB. <- This is the maths I'm thinking about doing to display the estimate to the user.

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • There are now!

  • Updated: Honey, I Shrunk The Vids 2.3.4

    Jump

  • Sweet as mate, cheers for the kind words! I hope it's useful - and if you run into any issues, or think of a feature you'd like to see, please do let me know. Bugs get fixed ASAP, and I always promise I'll at least consider new features because I'm having a lot of fun working on this thing! 😁