This should be a lightweight compression, capable of supporting HD with a reasonable bit-rate, hopefully supporting a wide range of web browsers. Proxy playback, for web review, and non-color critical workflows, e.g. However, there are still quite a few areas that a ffmpeg user could go wrong, which we break down below. Once we get to ffmpeg, the goal being that the pixel data we get in, should be as close as possible to the data we get out of ffmpeg. Presentation Linksįor this paper, we are assuming that we are encoding from a file-sequence of frames into a movie (rather than re-encoding a movie), but we are also assuming almost all of the colorspace work would be done outside of ffmpeg, with tools using the OCIO library. Where ffmpeg arguments, it would be great to document why we are using them, rather than ending up with a recipe. Q: Which container should we be considering: mov, mp4, mxf.How much should we be able to adjust color and have the image hold up? (Or rely on exr's for that?).Should any filmlook be baked in, or should we assume that is always applied during viewing.Lookdev/lighting/compositing movie playback - should have excellent color fidelity and minimal encoding artifacts.somewhat lower quality playback, but should always provide smooth motion. Animation/Modelling/Layout movie playback.web streaming), should be setup for web streaming. Rec709 and sRGB displays to start with, but eventually, P3, rec2020 and HDR displays.
We are looking for recommendations for the following:
0 kommentar(er)
