-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows support and improvements #9
Comments
Hi Richards, thanks for your input. 4:2:0 output is pretty much standard for H.264, but not for HEVC, so I suppose it needs to be configurable. What do you think? , the level something that should definitely be possible to s |
Definitely High Profile, not Main, probably hard-wired for all cases. And, I had only suggested Level 4.2 so ffmpeg didn't automatically choose a higher level, but if it always uses the lowest level for the task then the level can certainly be omitted. Actually, the reason for suggesting
is because ffmpeg does not automatically base the format on the output format chosen (e.g. MP4), it bases it on the input. I've always found it strange that it doesn't default to 4:2:0 for mp4 output unless specified otherwise, but many organisations store their Archive/Master copy as a better quality original. For instance, all our master input files are RGB 4:4:4. In this case ffmpeg will simply error and exit unless 4:2:0 is specified as the output pixel format, which we do in our strings by default. We had also recently switched to the double GOP length with forced keyframes to allow scenecuts, so it's nice to see that already included. The reason for suggesting a a way to specify some custom user settings or strings is similar to our pixel format requirement. For instance, we also currently set
for the same Master input from a different colour scheme. And/or people may also need to set x264 options depending on the input, such as
It isn't easy to design a tool for general use if it's wrapped inside an executable, as the user cannot change anything. Of course, if it's executed directly from the python file natively then the end user could modify the strings directly in the code. Anyway, there's a separate conversation to be had (maybe privately) about what is the best recipe for optimal encoding, but if there's a way to allow some add-on options (for ffmpeg, filters, x264) then it would cover more use cases. But I think a common encoding tool end-to-end would be great, rather than everyone currently trying to find their own chain of tools and settings to achieve conformance... |
Hi
I'm pleased to see an effort to provide a set of Media Tools for generation too. We use ffmpeg ourselves currently with other third-party packagers but it's a good idea to try to work towards a common best practice for the most common use cases.
There are a few issues with the current tool that I'd like to recommend for update.
Firstly, for the Windows command line a single-quote is not supported so please change to double-quotes, as used on the video/audio filters, i.e:-
Also, why not supply a Level for the High profile? It defaults to level 3.0, but common guidelines now seem to recommend level 4.2:
And finally, support for additional user-specified ffmpeg or x264 options would be great. For instance, we supply 4:4:4 input, so we need to specify an ffmpeg output option of:
(but other ffmpeg/x264 user-defined options would be a great feature for specific use cases depending on the workflow of the end-user)
The text was updated successfully, but these errors were encountered: