[–] [S] 1 point 1 week ago

Your GPU might support AV1 encoding, but svtav1 is a software encoder running on your GPU.

Libaom is also a software encoder but not optimized and extremely slow as you noticed.

I think the size differences simply come from the parameters you chose, each encoder has its own parameters, arguments, maximum and minimum.

If your NVIDIA GPU supports AV1 encoding, then via nvenc.

Here is documentation and how you can list encoders and their options:

https://ffmpeg.org/ffmpeg-codecs.html#Encoders

ffmpeg --list-encoders

#list encoder options, here example for the "quicksync video" encoder from Intel
ffmpeg -h encoder=av1_qsv

GPU encoding is extremely fast but does not have the benefits of svtav1

  • size is way bigger, at the benefit of speed
  • there might be very big blocky artefacts
  • no artificial noise generation and denoising, which make the image look smooth and add artificial grain, instead of trying to compress the grain and causing visible blocks everywhere. This is controversial but especially for
  • no multipass encoding afaik. Multipass is a fancy thing where the encoder analyzes a video first and then encodes it in the second run (as far as I know), so it "knows" the video better and can react to bitrate changes better and give smaller sizes

For livestreaming, GPU encoding is essential. For reencoding movies (always use the highest available quality, e.g. a 2160p Bluray remux -> 1080p AV1 encode) software encoders are way better.

I have an Intel Arc and basically gave up on GPU encoding because of horrible quality, maybe nvenc is better though.

  • source
  • [–] 1 point 1 month ago

    Not sure if I'm missing something, but that doesn't seem relevant to my desired workflows. I see your comment there so maybe you're replying to just my mention of the node-based aspect of this?

    Side-note, Natron is another thing like this (node-based video/compositing) though not exactly in this wave and probably more limited in scope.

  • source
  • parent
  • context
  • [–] 1 point 1 month ago* (last edited 1 month ago)

    I am not talking about programming, but that apps like this one use node graphs for asset production (that certainly won't have a speed issue when it's outputting* a file used elsewhere).

    Particularly the idea with node-based being flexibility. Something like SDF textures I guess can already be done via shaders like what you're talking about with Blender's visual shaders so would probably work here for anyone who knows what they're doing, some of what I'm talking about might need explicit support though (short of somehow finagling data into text enough to export to some text/binary format) especially editor-level features. Though even SDF is something that would be a lot better as a supported feature or plug-in.

    The video for this mentioned that 3D is a weak aspect so that probably doesn't help, particularly for the type of assets that don't use nodes much. Though even some simple parametric options would be nice.

    * I guess it could technically do live rendering, perhaps even via webGL/WASM or leaning on other tech that uses those. And that would be interesting.

  • source
  • parent
  • context
  • [–] 1 point 1 month ago (1 child)

    My only experience with node based programming is in Blender3D for shaders. It clicked way better than learning Python or GDScript ever did as it's all very visual, and I'm pretty good with visual.

    But I'm not sure if node based programming results in well optimised code. It's great for something you leave rendering over night, but a program you constantly use...? Dunno.

  • source
  • parent
  • context
  • [–] 1 point 1 month ago* (4 children)

    Even if they did make it, there's a lot of these node applications (they mentioned Graphite, Pixieditor is another). Makes me wonder if there was some Siggraph talk inspiring this, or if node-based workflow really does make a big difference. Or maybe similar library/toolkit usage?

    That being said, I've asked about this* a few times and never even get a response. So it makes me wonder if the supply outpaces the users on this one. Either way, there are 15 competing standards node-based everything editors.

    * and if certain workflows could work... like SDF textures, polygonal font creation (especially color, .otf result), indexed vertex colors+mesh library

  • source
  • parent
  • context