[vlc-devel] Cropping

Rémi Denis-Courmont remi at remlab.net
Mon May 25 10:43:05 CEST 2015


Le 2015-05-25 08:55, Steve Lhomme a écrit :
> From my understanding when a picture_t has an i_width/height,
> i_x/y_offset and i_visible_width/height, the planes should be
> allocated with width/height but only the visible area should be used
> and the offset handled to display the right position of that visible
> rectangle. Am I correct ?

The planes must be allocated with enough pitch and enough lines for at 
least width rows and height lines of pixels respectively. The planes can 
be even larger if the video output needs padding, or if there are more 
than one plane, and different planes need different padding.

> Also is the decoder supposed to decode the whole area
> (http://v2v.cc/~j/theora_testsuite/offset_test.fail.png) or it can
> take shortcuts to fill only the area it knows will be visible ?

The padding must be readable and writable by the decoder. The decoder 
is free to initialize it or not.

> If the vout cannot handle cropping by itself, is a crop filter
> inserted automatically in the vout filter chain ?

Sort of. Currently, swscale does the cropping. This is suboptimal but 
functional. We could have a "scaling" filter that only supports 1:1 
scaling to crop faster though.

> If so, how does the vout signal if it can handle cropping or not.

If the video output does not handle demuxer/packetizer/decoder/filter 
cropping, it must set the offsets to zero, and set the dimensions in 
accordance with the physical size of its picture buffer planes. XVideo 
does that (to avoid bleeding green from across the edges).

Note that "user" cropping must be supported (i.e. 
VOUT_DISPLAY_CHANGE_SOURCE_CROP) always.

-- 
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net/



More information about the vlc-devel mailing list