Skip to content
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

Open
richardbushell opened this issue May 6, 2019 · 3 comments
Open

Windows support and improvements #9

richardbushell opened this issue May 6, 2019 · 3 comments

Comments

@richardbushell
Copy link

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:-

-vf "scale=768x432"
-af "pan=stereo:c0<c0+c1:c1<c0+c1"

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:

-level:v 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:

-pix_fmt yuv420p

(but other ffmpeg/x264 user-defined options would be a great feature for specific use cases depending on the workflow of the end-user)

@TobbeEdgeware
Copy link

Hi Richards, thanks for your input.
The quotes is a bug.
The level depends on the resolution, frame rate and bitrate and should be automatic from x264,
so the only thing I thing should be changed is the profile (main -> high, or configurable). Do you agree?

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

@richardbushell
Copy link
Author

richardbushell commented May 9, 2019

@TobbeEdgeware

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

-pix_fmt yuv420p

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

-vf "colormatrix=bt601:bt709"

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

nal-hrd=cbr:force-cfr=1:videoformat=pal:fullrange=off:colorprim=bt709:transfer=bt709:colormatrix=bt709

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@richardbushell @TobbeEdgeware and others