[FFmpeg-devel] [RFC] libswscale and non-chroma-aligned slices

[Michael Niedermayer]

On Sat, Jan 09, 2010 at 11:22:10PM +0100, Stefano Sabatini wrote:
> On date Saturday 2010-01-09 18:20:03 +0100, Michael Niedermayer encoded:
> > On Sat, Jan 09, 2010 at 05:40:36PM +0100, Stefano Sabatini wrote:
> > > Hi all,
> > > 
> > > libswscale issues slices with weird heigth, for example:
> > > y:100 h:9
> > > y:119 h:9
> > > y:128 h:10
> > 
> > try again, this doesnt look very likely
> 
> stefano at geppetto ~/s/l/ffmpeg> ffplay -loglevel debug -vfilters "slicify=12, scale=200:149, pad=300:200:20:20:blue" in.avi ^| grep "scale *->pad"
[...]
> draw_slice      : link[0x9138b00 s:200x149 fmt:yuv420p          scale           ->pad             ] y:106 h:6 dir:1
> draw_slice      : link[0x9138b00 s:200x149 fmt:yuv420p          scale           ->pad             ] y:112 h:5 dir:1 <=
> draw_slice      : link[0x9138b00 s:200x149 fmt:yuv420p          scale           ->pad             ] y:117 h:5 dir:1 <=

thats fine, your example is not
... something with 100+9=119 ...


> draw_slice      : link[0x9138b00 s:200x149 fmt:yuv420p          scale           ->pad             ] y:122 h:6 dir:1
> draw_slice      : link[0x9138b00 s:200x149 fmt:yuv420p          scale           ->pad             ] y:128 h:4 dir:1
> draw_slice      : link[0x9138b00 s:200x149 fmt:yuv420p          scale           ->pad             ] y:132 h:6 dir:1
> draw_slice      : link[0x9138b00 s:200x149 fmt:yuv420p          scale           ->pad             ] y:138 h:4 dir:1
> draw_slice      : link[0x9138b00 s:200x149 fmt:yuv420p          scale           ->pad             ] y:142 h:7 dir:1
> 
> This was "discovered" by the new test system with random height
> slices, and results in a 2 lines gap in the pad output, since it
> aligns the y/h values.
> 
> The problem seems to appear only with odd values for the output
> height.
> 
> > > this with an yuv420p output, so I'd expect for each slice an height
> > > which is a multiple of vsub^2, that is:
> > > h == (h & ~((1 << vsub) - 1));
> > > 
> > > For example for the previous case I'd rather expect:
> > > y:100 h:8
> > > y:118 h:10
> > > y:128 h:10
> > > 
> > > I suppose the chroma components lines associated to the last luminance
> > > line is already filled, anyway it would be a lot simpler to make the
> > > scaler always return already chroma-aligned h values, this would
> > > simplify the logic required from each filter dealing with such slices,
> > > which gets complicated especially with negative slice direction
> > > values.
> > 
> > you have a video of yuv420p with vertical resolution of 9
> > how exactly will you avoid outputing a slice of odd height?
> 
> Yes that's exactly the problem I'm trying to resolve, having only one
> odd slice (either at the end either at the beginning of the slice
> sequence) would be way simpler to manage.
> 
> Also another way to consider is to lose the information of the odd
> line, in your example that would mean to output a single slice with
> height 8.

Iam not opposed to consider a patch to swscale that avoids half chroma
slices where possible, still the odd one at the end must be supported
by any calling code

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100110/ba050463/attachment.pgp>