On Sat, May 27, 2017 at 10:10:44AM -0400, Kevin Mark wrote: > Variables pertaining to the non-reference video are now available when > using the scale2ref filter. This allows scaling a video with another > as a reference point while maintaining the original aspect ratio of > the non-reference video. > > Consider the following graph: scale2ref=iw/6:-1 [scaled][ref] > This will scale [scaled] to 1/6 the width of [ref] while maintaining > the aspect ratio. This works well when the AR of [ref] is equal to > the AR of [scaled] only. What the above filter really does is > maintain the AR of [ref] when scaling [scaled]. So in all non-same-AR > situations [scaled] will appear stretched or compressed to conform to > the same AR of the reference video. Without doing this calculation > externally there is no way to scale in reference to another input > while maintaining AR in libavfilter. > > To make this possible, we introduce seven new constants to be used > in the w and h expressions only in the scale2ref filter: > > * other_w/other_h: width/height of the input video being scaled > * other_a: aspect ratio of the input video being scaled > * other_sar: sample aspect ratio of the input video being scaled > * other_dar: display aspect ratio of the input video being scaled > * other_hsub/other_vsub: horiz/vert chroma subsample vals of input > > Of course the only new constants needed for maintaining the AR is > other_w/other_h or other_a but adding additional constants in line of > what is available for in/out allows for other scaling possibilities I > have not imagined. > > So to now scale a video to 1/6 the size of another video using the > width and maintaining its own aspect ratio you can do this: > > scale2ref=iw/6:iw/(6*other_a) [scaled][ref] > > This is ideal for picture-in-picture configurations where you could > have a square or 4:3 video overlaid on a corner of a larger 16:9 > feed all while keeping the scaled video in the corner at its correct > aspect ratio and always the same size relative to the larger video. >
> I am not fully sold on the other_ prefix. It works but I'm open to > suggestions on something that is more concise or clear. Unfortunately > in_ is most clear but that is taken by the reference input, which in > my opinion, should've been labeled as such (not as in_ but perhaps > ref_). What is the best way to refer to this? The other input? The > scaled input? The non-reference input? main_* and ref_* are maybe prefixes that would work without conflicting with the existing ones [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
