On 10/07/2019 13:56, James Almer wrote: >> Heavily disagree. rav1e has its own 'tiles' option that determines the right >> cols/rows to use for a reason, and I will not be emulating libaomenc's algo >> instead of using the one provided by rav1e. It's confusing at best (since >> it goes against the rav1e API, and makes the official CLI and ffmpeg work >> differently). > > It's not libaom code, it's Mark Thompson's code. It derives > tile_rows_log2 and tile_cols_log2 values, which are what libaom expects, > from a Cols X Rows string (image size AVOption type), so you can tell > the encoder if you want a sample with exactly 4x2 tiles or such.
That should be handled by the tile-columns and tile-rows options below, I think. > > But if you prefer the tiles option to match the behavior or rav1e's CLI, > then I'm fine with it. I do prefer this. >> Why? What's the use-case? "Being the same as libaomenc" is not a good use >> case. > > Command line option consistency between encoders is a good reason. It's > why you're using "qp" instead of "quantizer" or whatever, after all. > Rav1e lets you set cols and rows in log2 values much like libaom, right? > Then why not add options that map directly to them? Even if you don't > use Mark's code to convert Cols x Rows strings, both a tiles and > tile-cols/rows options can coexist, with the latter two taking > precedence over the former, since they give the user more control over > tiling. That's fair enough, having users set log2 values is crappy. I'll add these. - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
