I haven’t found any posting that seemed to be what I mean, so I am starting a new topic.
When exporting to FFV1 lossless format, the GUI parameters are “thinking” lossy-only. Similar for PCM uncompressed audio export.
I’m also doing FOSS workshops in the AV field, and I’m always having a hard time explaining “why these fields don’t make sense here”
When I’m exporting to uncompressed/FFV1 myself, I always feel a bit uneven in my stomach, because “I’m not sure which parameters Shotcut is using exactly… - Except for the custom arguments textfield. That’s awesome!”
Is there anything we could do to facilitate such a patch?
Thank you very much in advance
And thanks for your great work!
Are you using the export presets? Or do you enter the Advanced settings? The advanced settings require some knowledge of how FFMpeg works. You can right click on an export job to view the generated MLT which includes the parameters that are passed to FFMpeg. Each parameter can be researched in the FFMpeg documentation for the respective codec.
I’m using FFmpeg all the time, and I know FFV1 quite well.
That’s not the issue
I meant that the actual GUI form fields only reflect parameters for lossy encoding formats.
I’ll attach a screenthos when I’m back on the video editing machine.
I’m unclear what the request is. Are you wanting to hide the lossy options when a lossless codec is chosen? Or are you wanting to add lossless options to the export screen? If the latter, what options need to be added? Most lossless codecs have very few options, and they are different between codecs.
For the most part, Shotcut does not have code that reconfigures the export screen for every possible combination of codec and parameter setting. That would be a huge and exception-prone list. “Advanced options” implies that the burden is on the user to understand which options have meaning for a given combination. Even though a bitrate field exists, FFV1 doesn’t look for that value, so in effect it will do nothing. I understand that non-applicable fields can be confusing to beginners, but it was called the “Advanced” panel for a reason.
Yes, it is not too big of a deal to maintain a list of lossless codecs using the output from ffmpeg -codecs. I will probably write a little awk script to keep in the repo to facilitate this (as opposed to running ffmpeg and parsing in C++ on every app launch). We can also keep a list of intra-only to disable GOP and B frames options.
Cool. Would libx264 at 100% quality count as true lossless? For all practical purposes of UI, the lossy options could be disabled for ProRes and DNxHD/HR and other intermediate formats as well, so long as the quality parameter was forced to 100%. ProRes will use less than standard bitrate if the quality is set to less than 100%. I’m just brainstorming with you.
NO, basically, these rules will only apply for only lossless or only intra codecs. Give an inch and they ask for a mile. I knew this would be a slippery slope.
For sure slippery. I wasn’t asking for this feature for myself because I already know the options. My main goal was to anticipate the questions and problems that others might have, to help make a smooth and simple implementation with reasonable and known limitations. If I didn’t ask about libx264, somebody else would.
I think you missed the point. The visually lossless codecs like ProRes and DNxHR do not offer bitrate control or B-frame or GOP options, so it is reasonable to disable the lossy export controls for them as well. The visually lossless codecs are detected and included by Dan’s awk script. I was not trying to make a case that they offer the same export quality.
I tested this with the 23.11.01 artifact and it worked well for most codecs! However, there were some alternate encoders and image formats that didn’t get picked up in the scan (prores_ks being a notable one). So, I tweaked the ffmpeg-codecs.sh script and hand-reviewed the results. I can create a pull request if you want. Depending on your review, this would of course impact encodedock.cpp as well.
You can do everything with awk alone. No need to use grep, pipes, cat, sort, and printf. Sorry, not very interested in maintaining your changes to the script.
My primary interest was seeing if prores_ks, ffv1, png, and qtrle could be added to the current Intra-Only list since they are popular encoders and Shotcut has bundled export presets that use them. My abomination of a script was a modular attempt at being able to regenerate the codec list from scratch if needed (ie, FFmpeg major version upgrade with new codecs released), while preserving any manual overrides to the list (such as the four I mentioned). The code could be much cleaner by using temp files, but I didn’t know how this script fit into the build pipeline, so I made the script output identical to the current version. But again, I have no attachment to that script or the general method. I was mainly interested in the fate of those four codecs. After all, the title of this thread is “Exporting as FFV1” but the current Intra-disable list does not include FFV1 yet. I’m genuinely trying to help and not just be pedantic.
OK, but it is also more about lossless, and there it is covered. I do see now that ffmpeg -codecs output shows lines with “encoders:” that contains names that supersede the name of the codec in the second column. webp is a good example; there is no webp encoder, only libwebp and libwebp_anim. As for ffv1 being intra-only, it does not show in the list. This Wikipedia paragraph explains that, and this: https://trac.ffmpeg.org/wiki/Encode/FFV1#FFV1version31
I was able to expand the awk script to extract “encoders:”. But I am not too keen to hard-codec additional ones that ffmpeg -codecs does not show as intra-only. I am also only using the Shotcut ffmpeg build and not one that includes every library possible such that might be in a distribution package.
Understandable on all points. The awk-split code you added is pretty cool. Thanks for revisiting the topic. I don’t plan to go any further down the slippery slope!
I wasn’t asking for this feature for myself because I already know the options. My main goal was to anticipate the questions and problems that others might have, to help make a smooth and simple implementation with reasonable and known limitations. If I didn’t ask about libx264, somebody else would.