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.
More information about the vlc-devel