On Mon, 26 Oct 2015 12:56:31 +0100 Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> >> > I think doing cropping as metadata would also simplify code a lot. For > >> > example, nobody has to worry about non-mod-2 yuv420 anymore, and how it > >> > should be handled. It's less tricky, more correct, more efficient. > >> > >> OK. A crop side-data is desired then. I somehow was convinced that it > >> wouldn't matter for SW. Though, it would actually be really need that > > > > At least this is my opinion. I would like to have such cropping side > > data, instead of half-broken ad-hoc cropping in the decoder and things > > like coded_width. > > > > I don't know what most others think about this. I suspect most would > > find such a change too intrusive. At least for hwaccel it's mandatory > > though. (What we currently do just barely works, and I need hacks in my > > own code to reconstruct the real surface size.) > > 99% of all cropping use-cases are extremely simple (only bottom/right) > and don't require any secret magic in any code. > I don't mind adding extra cropping metadata, but if you just don't > care about top/left cropping, simply adjusting width/height is as > trivial as it gets. > > Adding mandatory new metadata that every user app has to support to > avoid getting 1920x1088 in the future seems a bit ill-advised. Well, I've seen you complaining multiple times that non-mod-2 yuv420 does not make any sense... _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel