1. Can we please have the option to configure export codecs (set bitrate) for video and audio exporting?
I see in the credits that Moho uses the brilliant FFmpeg library to convert audio and video for exporting, so I don't understand why we are not given the option to set bitrates for both audio and video when choosing a lossy compression like H.264. FFmpeg provides this functionlity, Moho only needs to enable it, so it should be an easy fix?
2. Can we have the option to export uncompressed audio (of the timeline) without video, again this is something FFmpeg already provides.
3. FFmpeg supports GPU encoding for many codecs like H.264 and HEVC, if Moho enabled this then render times could be improved.
I noticed that the current preset for H.264 (MPEG4-AAC) is set compress audio down to 128kbps which is unnecessarily poor, this does not change even if you select 4k video export.
4. It would be nice if we could also have a custom text box where we can type our own custom parameters for FFmpeg. I would give us ultimate freedom for exports. I understand FFmpeg has some great professional quality filters and other goodies such as abiity to hard code subtitles.
gpu base codec is not useful when you need to wait for render completion.
moho by default use high quality settings in h264. it's not good idea to decrease quality in animation softwares.(rerender if quality was poor !)
خیام اگر ز باده مستی خوش باش
با ماهرخی اگر نشستی خوش باش
چون عاقبت کار جهان نیستی است
انگار که نیستی چو هستی خوش باش
I'm not really familiar with the core software engineering but if we have an option to enable/disable GPU while working - how difficult is enabling "re-routing" of the render from CPU to GPU?
If that is a problem, how more/less complicated it is to have a saying on which codec would be applied in CPU render?
Since I really don't know much about these things - is asking about these options somewhat silly?
In regards to silly - one of the export options is flash/swf files but if you'd go for a QT ProRess4444 - well, go to the 32bit edition of Moho. So, in order to have a current (modern?) format, you'd need to go for a less current system edition of the same sw?! Usually, in either animation or editing sw, expecting to have render options available to users is not that silly.
davoodice2 wrote: ↑Thu Jun 30, 2022 7:30 pm
gpu base codec is not useful when you need to wait for render completion.
moho by default use high quality settings in h264. it's not good idea to decrease quality in animation softwares.(rerender if quality was poor !)
Sorry I missed these replies, just seeing them now.
I didn't understand what you meant by "gpu base codec is not useful when you need to wait for render completion." FFmpeg library which is built into Moho can already use GPU hardware assisted encoding for h264 and HEVC codecs with NVIDIA hardware. It would be nice to be given the option to switch this on, then depending on our hardware we may see some gains in render time. If you look when rendering the final thread running is the "video encoding" thread - this thread could be off loaded to the GPU freeing up CPU for other threads. Yes its true that for a given bitrate, encoding in software (cpu) will always give you slightly better results, but GPU encoding can be much quicker (typically 2-3x faster), and some of the finer quality loss can be made up by uping the bitrate. A good compromise would be to use GPU encoding during development and then for final render switch to software cpu encoding.. or if final render will be png sequence for composition software then it doesn't matter as it will be done in cpu anyway. At the moment, during development, we typically have to render at half resolution to keep render times down, this wouldn't be necessary.
Regards codec quality setting, the default video quality setting is ok but not brilliant. For example, encoding h264 at 1080p the bitrate is around 10-11000kbps (in comparison DVD at a much lower resolution 560p is around the same bitrate). The default audio bitrate on the other hand is terrible at just 128kbs. With ability to cusomise codec settings, we could if desired increae the render quality.
Maestral wrote: ↑Sat Jul 02, 2022 12:19 pm
I'm not really familiar with the core software engineering but if we have an option to enable/disable GPU while working - how difficult is enabling "re-routing" of the render from CPU to GPU?
If that is a problem, how more/less complicated it is to have a saying on which codec would be applied in CPU render?
Since I really don't know much about these things - is asking about these options somewhat silly?
In regards to silly - one of the export options is flash/swf files but if you'd go for a QT ProRess4444 - well, go to the 32bit edition of Moho. So, in order to have a current (modern?) format, you'd need to go for a less current system edition of the same sw?! Usually, in either animation or editing sw, expecting to have render options available to users is not that silly.
You are absolutely right Maestral, giving us the option to customise codec settings, especially when the ability to customise is built in to Moho via the FFmpeg library, is not silly.. its common sense. And in fact is a necessity given how poor the default setting for audio encoding are.
Thank you both for the input. I finally understood the logic behind the choices (compromises) made within Moho's 'structure'.
Time is on our side, I guess. Moho is in good hands so I believe things could only get better.
Unfortunately I don't think time is on our side. When Moho came out it really was the cutting edge "all-in-one animation tool", but I think perhaps its been in the wrong hands for a while and hasn't received the attention it deserved, and now that its in the right hands, there is a lot of catching up to be done in many fundamental areas.. (Yes I know in rigging its elegance has stood the test of time and is still champ).
I think this issue of customising export codecs, especially providing a usuable audio export (even youtube recommends "384 kbps audio bitrate for stereo" with "Sample rate 96khz or 48khz", while moho only provides 128kbps at 44.1kHz) could have been best addressed when the new codec options were added to Moho last November in v13.52.
I personally do not understand the choices made, especially as things seemed to have been unnecessarily compromised - FFmpeg gives moho a flexible, powerful export module for free, so why cripple it?
Since I don't know how much work(hours) is needed or what might be impacted by enabling GPU render, adding codecs options, and similar tasks within the core of sw - my understanding is priorities were sorted this way.
Although it could seem 'normal' to have a certain level of export quality - on the other hand, Moho provides options for animations which are not available or at least not that flexible in other software. Current export options are enough for further editing in some other, dedicated software. I'm used to such an approach but for a moment it seemed to me that certain groups of users might be repelled by lacking some of these export options.
Personally, I'm not really fond of all-in-one sw's (of any kind or purpose) and if you have great options for animating (almost in constant development followed by improvements) - dealing with export quality externally is not that much of a hassle.
In short - animation tools and options in Moho could meet your requirements but you can't be bothered to deal with export quality externally? I'm not familiar with nor could greet such an approach.
Maestral wrote: ↑Sat Jul 09, 2022 6:29 pm
Since I don't know how much work(hours) is needed or what might be impacted by enabling GPU render, adding codecs options, and similar tasks within the core of sw - my understanding is priorities were sorted this way.
Although it could seem 'normal' to have a certain level of export quality - on the other hand, Moho provides options for animations which are not available or at least not that flexible in other software. Current export options are enough for further editing in some other, dedicated software. I'm used to such an approach but for a moment it seemed to me that certain groups of users might be repelled by lacking some of these export options.
Personally, I'm not really fond of all-in-one sw's (of any kind or purpose) and if you have great options for animating (almost in constant development followed by improvements) - dealing with export quality externally is not that much of a hassle.
In short - animation tools and options in Moho could meet your requirements but you can't be bothered to deal with export quality externally? I'm not familiar with nor could greet such an approach.
Maybe I didn't explain properly. I think there are two categories - would be nice to have, and essentials.
GPU rendering would be nice to have but certainly not a high priority for me personally. Given the choice I would prefer they focus their attention on proper GPU enabled modeling so there is consistency in the workspace - display of masking, etc so we dont have to keep pressing ctrl-r to see what we are doing, rather than spend time on gpu rendering. I only raised gpu rendering as FFmpef already supports it so it should be an easy fix to switch it on (unlike fixing the workspace which could be difficult to fix).
An essential requirement in my opinion is the ability to export both video and audio synced in an uncompressed format or in a compressed format at very high bitrate so if you have to pass the export through another program (for composition, subtitling, etc) you will not see a drop in quality when it gets re-rendered for final export. Personally I dont have a problem with video quality, as there is a work around - render in moho at a higher resolution eg 4k when final output needed is 1080p. But unfortunately this isn't true for audio. No matter how good the audio you import in to moho, it will reduce it to 44.1kHz 128kbps, so its not a case of "you can't be bothered to deal with export quality externally".. the quality is destroyed before export, you cant bring back 48khz uncompressed wav once its been reduced to 44.1khz 128kbps. So this is a problem that does need fixing as a priority. This can easily be fixed by allowing us to customise the setting sent to FFmpeg for encoding (I think other programs that use FFmpeg like Opentoonz allow this). Of course allowing us this would also fulfill all the other 'would be nice' items on the list - a win-win.
