[FFmpeg-devel] Slice direction in swscale.

[Ramiro Polla]

On Tue, Sep 8, 2009 at 8:57 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Sep 08, 2009 at 05:49:19PM -0300, Ramiro Polla wrote:
>> On Mon, Sep 7, 2009 at 3:31 AM, Ramiro Polla<ramiro.polla at gmail.com> wrote:
>> > In sws_scale() there is some code to adjust src and srcStride if it
>> > seems the slices go from bottom to top. This is traced back to r15249,
>> > and the discussion leading to the patch is here:
>> > http://thread.gmane.org/gmane.comp.video.mplayer.devel/25600/focus=25615
>> >
>> > I have also stumbled upon this:
>> > http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/42415
>> >
>> > I have not been able to test this code, not even with the sample
>> > pointed at the first link above. The sample plays something very
>> > distorted in ffplay, something with a badly scaled chroma in mplayer,
>> > and plays properly in vlc.
>> >
>> > Does anyone know of a sample that triggers code? Certainly it's not
>> > with ffmpeg/ffplay, since we run sws_scale on the whole picture
>> > instead of slice-based, but I suppose this could be tested with
>> > mplayer.
>> >
>> > Anyways the sliceDir check is very hackish and undocumented. Would it
>> > be acceptable for this to be removed and always require top-to-bottom
>> > strides or expect the user to flip things himself?
>>
>> Alternatively we could document it with attached patch.
>>
>> Ramiro Polla
>
>> ?swscale.h | ? ?3 +++
>> ?1 file changed, 3 insertions(+)
>> cad71f58ca1ef8fb0a27b0885eb0e819b587b227 ?document_slices.diff
>> Index: swscale.h
>> ===================================================================
>> --- swscale.h (revision 29662)
>> +++ swscale.h (working copy)
>> @@ -136,6 +136,9 @@
>> ? * Scales the image slice in srcSlice and puts the resulting scaled
>> ? * slice in the image in dst. A slice is a sequence of consecutive
>> ? * rows in an image.
>> + * Slices can be bottom to top or top to bottom.
>
> ok

Committed.

>> ?The direction will be
>> + * detected in the first call and must be maintained throughout all
>> + * subsequent uses.
>> ? *
>
> i think this should be easy to fix, do we need more than reseting SliceDir?

How far do we want to support changing slice direction? In a per-frame
basis, or in a per-slice basis? (as in we track continuity and check
for the corner cases Y==0 or Y+H==height). Per slice would scale
incorrectly because we would use old buffers.

Ramiro Polla