What is your operating system?
Win 10 (RDNA3) & Win 11 (GCN 1.0)
What is your Shotcut version (see Help > About Shotcut)?
Tested with 24.02.29 & 24.04.13
Can you repeat the problem? If so, what are the steps?
Please excuse if I’m not an expert on these things, but I’ll try to keep it concise and brief:
1.) There doesn’t seem to be a sanity check for serving invalid parameters to AMF. In my case, GCN 1.0 can hardware-encode only H.264 up to 1080p60. Source material with a larger resolution will encode “normally”, not trigger an error message at the start. Resulting file only contains an audio stream.
2.) I bought a RX7600 specifically for AV1 support, but I simply couldn’t render any valid results by using Shotcut regardless of settings.
-
Using default export settings, files are way too large in comparison to amf_H265 or sometimes even H264. Example for a 5 min 4K video of some old video game: H.264 (701mb), H.265 (221mb), AV1 (611mb). File sizes in OBS, also using AMD AV1, are as large as expected.
-
Disregarding file size, every single rendered video thus far was broken. Audio is fine, but trying to skip ahead breaks the video stream and only statically shows the last frame. Happens in both VLC as well as Shotcut itself. No such problem with AV1 encoded through other means (AV1 software, AV1 hardware via OBS or Handbrake).
Hope I described the problem as best as possible. Thanks for reading.
That is not implemented pretty much for any encoder, hardware or otherwise. There would be a ton of code and testing to implement this for the many of the options of every encoder, bugs would be created as a result, and no one has volunteered to do it. Will you? The workaround is to read the export job log for clues when something goes wrong.
files are way too large in comparison
There is no adjustment or scaling of parameters to every codec variation on every OS. Again, too many combinations for our intentionally simple (i.e. maintainable) code. The defaults are setup for quality-based VBR. The quality % is a simple linear mapping to the range of an encoder parameter such as crf, cq, qp, or qscale. The default % is setup for the software encoders to produce an expected small H.264, smaller HEVC, and smallest AV1 result. However, these same % are used with the hardware encoder, and each encoder decides what that crf/cq/qp/qscale value means. In summary, you may need to adjust the quality % to achieve your goal.
When we include VP9 in the mix, there are 4 software encoders regardless of OS, 3x4 hardware encoders on Windows, 2 hardware encoders on macOS, and 3x4 hardware encoders on Linux. If we put them into a table and try to find a suitable default % value for each that would give 30 rows. But that only covers the defaults and would not apply to any presets unless there is some formulas for conversion to derive from this table.
Fair enough! Thanks for the explanation. Though like I said, I did try multiple ways to get AV1 going (not just quality-based %), also multiple containers, different drivers and nothing changed. I would think there aren’t many people using RDNA3 & Shotcut & AV1 & Windows? Didn’t find anything about this problem anywhere when I was looking around.
I have a RX7600 that I bought for development and testing prior to releasing it, but I only tested it lightly. I only verified that it could generate an AV1 WebM, and it plays back in Windows Movies & TV on Windows 10, which it did (but slowly on the old machine used for test). Today, I tried seeking on that file in Movies & TV, and it worked. Next, I just tested reducing quality % and changing format to MP4. It did make a smaller file, and it plays and seeks in Movies & TV. While both do have a problem seeking in Shotcut and VLC, they do play sequentially. I do not yet know what is needed to make them seekable. I do not have the problem with libaom-av1 encoded files.