Quoting Vittorio Giovara (2016-12-19 13:18:13) > On Mon, Dec 19, 2016 at 1:02 PM, Anton Khirnov <an...@khirnov.net> wrote: > > Quoting Vittorio Giovara (2016-12-19 10:11:29) > >> I have a couple of points about this, in random order: > >> > >> 1. I had thought agreement was more towards a side data type rather > >> than full types, is there any advantage with this approach? > > > > CertainPeople(tm) claim that this is such an essential information about > > the frame that it should live directly in it. I do not have a strong > > opinion on the matter, so whatever is least objectionable to most people > > is fine with me. > > OK, I wasn't too sure about it, I'm fine either way. > > >> 2. I would agree about having a full rectangle not two directions > >> only. Possibly I would keep naming consistent with coded_width and > >> coded_height as fields for uncropped size, and width and height for > >> cropped size. Optionally left and top could be marked as offset. > > > > Others seems to prefer that width/height are the pure original coded > > values, with a full cropping rectangle. > > The same CertainPeople(tm)? I do think changing semantics between > avctx and avframe is a BadIdea(c).
Well, strictly speaking the avctx fields should not be used at all during decoding. > > >> 3. What about container cropping? eg mov > > > > The caller's job. > > Yes, but this is currently handled by the demuxer overriding the size > of avcodeccontext, it would be nice to unify this behaviour once and > for all. I do not think it can or should be unified. The demuxer may say one thing, the decoder another. It is not our job to decide who is right. The demuxer and decoder should export the information stored at their respective layers as faithfully as possible and let the caller choose the correct one. > > >> 4. Does this support unaligned cropping? If not what happens to the > >> options about it? > > > > Read the following patches to find out. > > This point is important enough that it should be mentioned in the > commit log of this patch. This patch does not deal with data alignment at all, so why should that be mentioned in its commit message? > > >> 5. What about Theora? > > > > What about it? > > You can have cropping in it, see theora.pdf ยง 2.2, our decoder > currently supports it. All decoders should eventually be converted to crop through this mechanism, but not necessarily all at once. IOW watches pelcome. > > >> 6. Regarding 2/4, can you add a "third" way for apply_cropping so that > >> it exports uncropped values but automatically adds the crop filter > >> (kinda like we do for autorotate) and returns the filtered image at > >> the cropped dimensions? > > > > avcodec is unable to add any filters. If you wanted to call lavfi from > > lavc, j-b would personally strangle you. > > no no, sorry I meant from avconv, similar to how the transpose and > other filters are added. Yes, I have plans to handle this in avconv eventually. -- Anton Khirnov _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
